Meridian.

The problem

Reservations look like a UI problem and are actually a correctness problem: availability, rates and payment confirmations must stay consistent under concurrency. The interesting question was how to make double bookings and phantom payments structurally impossible instead of handling them in support.

What made it technically interesting

Availability has to be checked at the moment of booking, under concurrency — two users booking the last room at the same time must both get a truthful answer.

Payment state and reservation state live in two systems (the app and the payment provider). Keeping them synchronized is where most booking systems drift.

Each property needs its own identity, but a per-property fork would make every fix a fleet-wide operation.

Decisions

Availability as the core invariant

Reservations, holds and rate restrictions all go through one availability service with transactional checks. Double bookings became structurally impossible instead of a support ticket.

Payments confirmed by webhooks, not redirects

A reservation only confirms when Stripe's webhook arrives — a user closing the tab after paying can no longer create a phantom booking.

Per-property theming without per-property code

Palette, typography and imagery are configuration data, not forks — a new property is an onboarding step, not a deploy.

Result

• The availability service makes conflicting reservations impossible at the database level, not by convention.
• Payment state can only advance through webhook events, so the system can never show a confirmed booking that wasn't paid.
• Properties are data — the prototype demonstrated that a new property needs no code changes.