Thirty booking platforms, and one calendar that has to be right. — A case study
A search becomes a shortlist.
Before
Search is where a marketplace of this size gets slow. Geography, a date range, a guest count and a stack of filters, resolved against thousands of properties across several regions — and a traveller who waits for that is a traveller who goes back to the platform they came from.
Now
One multi-parameter query carries geo, dates, guests and filters together rather than narrowing in stages. It resolves server-side against tuned SQL, with the high-traffic paths cached, so a result set arrives at the speed of a keystroke instead of a page load.
- Geo, date, guest and filter logic in a single query
- Server-side APIs over indexed, tuned SQL
- Caching on the paths that carry the traffic
- Thousands of properties, across multiple regions
A shortlist becomes a reservation somebody owns.
Before
A booking that is only written down is a liability. Dates overlap, prices drift between what was shown and what was charged, and the guest and the host each end up believing something slightly different about the same night.
Now
Reservations pass guardrails and validation before they are ever held, so the state a guest sees is the state the host has. From that point the two of them talk to each other directly — which is not a feature bolted on the side, it is the whole reason the product exists.
- Reservation guardrails and validation before a hold
- Direct guest-to-host communication, no gatekeeper
- Subscription workflows for paid users
- Admin impersonation, so support reproduces a session rather than guessing at it
One calendar becomes thirty.
Before
The hard part was never this platform. It was the twenty to thirty others the same property is listed on. A booking taken here that does not reach a channel manager over there becomes a double-booking — and a double-booking is the one failure a host does not forgive, because it is their guest standing at a door that is already occupied.
Now
Partner sync services publish and consume availability and reservation events across a message queue, so a night sold here closes there, and a night sold there closes here. The services are containerised and scale per region, because the sync cannot be the thing that falls behind at the busiest hour of the year.
- Integrations with PMS, channel managers and booking networks
- Event-driven sync over a message queue, both directions
- Availability and pricing reconciled continuously
- Containerised services, scaled per region
A short-term rental marketplace built on a simple premise: travellers book directly with hosts, and neither side pays a platform commission. We built the search engine, the host-facing property tools, the partner sync services and the support tooling behind it, and scaled it past 10,000 active users. The client is under NDA.
The product exists to take the middleman out of a booking. Travellers pay less because they are not funding a commission; hosts keep the revenue they earned; and the two of them talk to each other directly rather than through a platform that owns the relationship.
That premise has an awkward engineering consequence. To be a real alternative rather than a smaller copy, the platform has to carry inventory that already lives on twenty to thirty other rental platforms, each with its own property management system, channel manager or booking network, and each entitled to sell the same nights you are selling.
So the work divided into two halves that had to hold at once: a marketplace fast and trustworthy enough that a traveller would book on it, and an integration layer honest enough that a host could list on it without fear of being double-booked.
Built on
- Next.js
- The traveller-facing marketplace and the host dashboards.
- Nest.js
- The booking core, the partner sync services and the APIs behind both.
- PostgreSQL
- Properties, reservations, pricing and availability.
- RabbitMQ
- The event backbone the partner integrations run on.
- ImageKit
- Property imagery, transformed and delivered at listing scale.
- Kubernetes & Docker
- Containerised services, scaled per region.
- Digital Ocean
- The infrastructure it all runs on.
Talks to
- Property management systems
- Channel managers
- Booking networks
What changed
- Scaled to 10,000+ active users
- Thousands of properties carried across multiple regions
- Travellers book directly with hosts, with no platform commission on the booking
- Hosts keep the booking revenue rather than surrendering a cut of it
- Guests and hosts hold the conversation themselves, with no intermediary in it
- Availability stays consistent with the external networks a property is also listed on
- Support can reproduce a user's exact session to debug an account
The hard part is usually the system you don’t control.
Most platforms are not held back by the code inside them but by everything they have to stay in agreement with. If that is the shape of your problem, describe it and you leave the first conversation with a scope, a budget and a ship date.