02INVENTORY WITH SAFE RETRIES
Inventory with safe retries
Built a NestJS and MySQL inventory service for holds, commits, cancellations, idempotency, expiry, compensation, and reconciliation.
NestJSMySQLIdempotency
FULL STACK DEVELOPER / BACKEND FOCUS
Full stack developer focused on backend systems.
I am a full stack developer from Sri Lanka. Most recently, I was an Associate Software Developer at Hotels Hippo.com (Pvt) Ltd, where I had technical responsibility for the product area used by guests. My work covered Node.js, AWS, search, booking, inventory, data pipelines, React, and Astro.
NOWOpen to full stack work focused on backend systems in Sri Lanka
SEARCH DATA FLOW READ MODELS
SOURCE / READ MODELS / GUEST SEARCH
01MYSQLauthority
02CDCtwo paths
03ELASTICSEARCHfilterable catalogue
04VALKEYavailability with a short delay
LISTING REQUESTfilter + availabilityroom suggestions / price
BUSINESS RISKFRESHNESS MATCHES DATA TYPE
3+ years
production experience
guest platform
~ 9 to 16k
historical availability coverage
documented period
379.31 ms
historical browser median
30 populated searches
2 paths
read paths
catalogue + availability
01 / BACKEND WORK
I changed the backend as the product grew.
The listing path started with MySQL and Node.js. As the catalogue and availability data grew, I moved reads into separate models so search stayed fast and the main database was not overloaded.
FEATURED SYSTEMLISTING / SEARCH
The read side changed as the data grew.
I explored a PostgreSQL read and synchronization path, then worked through a production Neo4j and C++ service and the Debezium, Kafka, and StarRocks generation. The final design documented at handover used AWS DMS CDC to feed two read models: catalogue data through S3 and Lambda into Elasticsearch, and availability with a shorter delay through Kinesis and Lambda into Valkey.
↳Elasticsearch handles catalogue filters. Valkey handles availability with a shorter delay. MySQL remains the source of truth.
See the full work 01 / STARTING POINT
MySQL + Node.js
The first listing path read from MySQL and processed broad availability in Node.js.
- Source of truth
- MySQL
- Read model
- None. Node.js read and processed MySQL data on request.
- Sync or request path
- Request time reads
SOURCEMySQL
- Branch 01Request pathMySQL → Node.jsOUTPUTGuest listing response
WHY I CHANGED IT
It was the simplest place to start. As the catalogue and inventory grew, this query path became too slow.
ReactNode.jsMySQL
02 / SEPARATE READ PATH
PostgreSQL experiment, then Neo4j + C++
I explored a PostgreSQL read path, then built the production Neo4j and C++ listing service with room and suggestion logic.
- Source of truth
- MySQL
- Read model
- A PostgreSQL read model experiment, then a Neo4j listing model.
- Sync or request path
- Database triggers and separate synchronization paths
SOURCEMySQL
- Branch 01PostgreSQL pathMySQL → triggers → PostgreSQLOUTPUTPostgreSQL read model
- Branch 02Neo4j pathMySQL → sync → Neo4jOUTPUTNeo4j + C++ listing
This was an intermediate phase, not the final handover design.
WHY I CHANGED IT
It improved filtering and room combinations, but it also added more services for a small team to maintain.
PostgreSQLNeo4jC++
03 / CDC PIPELINE
Debezium to Kafka to StarRocks
Change data capture replicated source changes into a queryable availability model, allowing listing reads to move away from MySQL.
- Source of truth
- MySQL
- Read model
- StarRocks availability and property search model.
- Sync or request path
- MySQL binlog → Debezium → Kafka → consumer
SOURCEMySQL
- Branch 01CDC pathBinlog → Debezium → Kafka → consumerOUTPUTStarRocks read model
A historical self managed pipeline that needed more operational work than the team wanted to carry.
WHY I CHANGED IT
It worked, but running Kafka and the analytics stack took too much daily attention.
DebeziumKafkaStarRocks
04 / FINAL DESIGN
DMS to read models
The final design used DMS to feed two read models. Catalogue data moved through S3 and Lambda into Elasticsearch. Availability moved through Kinesis and Lambda into Valkey.
- Source of truth
- MySQL
- Read model
- Elasticsearch for catalogue filtering; Valkey for availability.
- Sync or request path
- Two sync paths with different update delays
SOURCEMySQL
- Branch 01Catalogue pathDMS → S3 → LambdaOUTPUTElasticsearch
- Branch 02Availability pathDMS → Kinesis → LambdaOUTPUTValkey
MySQL remains the source of truth. Catalogue updates may arrive later; availability updates have a shorter delay.
WHY I CHANGED IT
Catalogue data could arrive later, while availability needed a shorter delay. Keeping the paths separate made the system easier for the team to maintain.
DMSLambdaElasticsearchValkey
02 / FULL STACK WORK
I also worked across the booking flow.
03BOOKING WORKFLOW
One booking flow across booking types
Unified direct, bid, and request and offer bookings around one flow controlled by the server for cart, pricing, payments, webhooks, and expiry.
Node.jsPaymentsState
04ROOM ALLOCATION
Room allocation in Node.js
Moved a specialised C++ room combination path into Node.js and kept the capacity and pricing rules covered by tests.
C++ to Node.jsConstraintsTesting
05PARTNER INTEGRATION
A B2B integration that handles bursts
Built an asynchronous Bakuun integration with API Gateway, Lambda, and SQS FIFO so partner updates could be queued and processed in order within each message group.
API GatewayLambdaSQS FIFO
06DELIVERY AND OPERATIONS
Cloud delivery and handover
Worked on image transformation, cache rules, AWS roles, deployment, runbooks, and final handover documents.
CloudflareAWSDocumentation
03 / WORKING PRINCIPLES
Rules I keep in mind.
A few rules I keep in mind when I change a system.
Keep the source of truth clear
Bookings and payments should write to one authoritative system. Search can use read models that can be rebuilt and refreshed at the right pace.
Remove work from the request
A faster language can help, but removing unnecessary work from a search request usually helps more.
Make the system easier for the team
A design is useful only if other developers can debug it, change it, and run it after I move on.
ABOUT ME
I follow a feature from the browser through the systems behind it.
I moved between product work and backend systems. Following the data from the guest experience to the source of truth helped me make better decisions and leave clearer code for the next developer.
Read about my background01
2022
Joined Hotels Hippo.com (Pvt) Ltd
Joined as a trainee working mainly in React and frontend development.
02
2023
Became an Associate Software Developer
Moved into Node.js, MySQL, APIs, booking, listing, and the rest of the guest product.
03
2024 to 2025
Worked through the difficult parts
Worked through the Neo4j/C++, Kafka/Debezium, and StarRocks versions as the platform grew.
04
2026
Completed the final handover
After my official employment ended on 30 June 2026, I completed the final handover on 7 August 2026, including the room allocation work, AWS read model documentation, and system handover notes.
CONTACT
Open to full stack work focused on backend systems.
I am looking for full stack work with a strong focus on backend systems. I work best on APIs, search, booking flows, data pipelines, and AWS.
Based in Sri Lanka. Available for my next role.
See how I workAVAILABLE FOR FULL STACK AND AWS WORK2026