Project 03 · Case study
Travel-commerce integration platform
Normalizing hotel-provider inventory, protecting booking paths, and making a multi-provider product operable.
Full-stack engineer and technical lead · end-to-end product and platform work
On a travel-commerce platform, I work across provider integrations and the transactional workflows around them. The engineering problem is specific: make incompatible providers feel like one usable product without hiding the failure paths the business needs to handle.
01 · The integration problem
Different provider contracts, one product surface
I built provider adapters over mismatched REST and XML APIs behind one normalized listing model. That included cross-provider room matching and deduplication so comparable inventory could be presented coherently.
The implementation work covered room-name decomposition, dedup grouping, matched-room merging, provider-agnostic alternatives, and bounded provider fan-out.
02 · Transactional paths
Design the path around the moments that can go wrong
A search result is not the end of the workflow. Rates can expire between search and booking, providers can be slow, and a payment can arrive before fulfilment is complete.
I worked with just-in-time rate handling, bounded provider calls, idempotent payment webhooks, provider order references persisted before polling, atomic confirmation claims before voucher delivery, and queued fulfilment paths.
01 · Provider boundary
Normalize without pretending sources are identical
Adapters kept provider-specific contracts at the boundary while the product used a shared listing model and matching logic.
02 · Money path
A retry must not double-charge
Durable provider references and idempotent webhook handling protect a payment and booking workflow from unsafe repetition.
03 · Operations
Make recovery diagnosable
Sentry coverage across web, routes, scheduled work, and queue workers supports investigation without placing PII in logs.
03 · Delivery practice
The product has to remain operable after integration work ships
I lead the client roadmap and technical meetings, write design specifications ahead of implementation, and review delivery work. The same work spans Docker deployment, queue workers, customer communication, admin tooling, accessibility, internationalisation, and operational recovery.
Evidence treatment · contribution map
The parts of the product I worked on
Scope is deliberately grouped by my ownership boundary. It is not a claim about the whole system.
Built
- Provider adapters over REST and XML APIs.
- Cross-provider room matching and deduplication.
- Search and booking workflows across provider boundaries.
Hardened
- Idempotent payment-webhook handling.
- Race-safe pricing and queued fulfilment paths.
- Provider-order reference and confirmation safeguards.
Operated
- Sentry coverage and no-PII logging practice.
- Docker deployment and release work.