Booking marketplace engineering — three verticals, one reservation model.

A booking marketplace is not a catalog with a checkout. It is a reservation system whose correctness is judged at two moments — the moment of booking confirmation, and the moment the consumer physically arrives. Between those two moments, inventory must be held, communicated to the operator, recovered on cancellation, and reconciled against the money that moved. Every one of these transitions is adversarial: consumers abandon, operators miss notifications, networks drop midway through a webhook.

The engineering discipline here is reservation state machines under three heterogeneous vertical semantics and three client roles. Hotels reserve nights. Restaurants reserve time windows. Rentals reserve dated assets with pickup and return events. Each vertical has its own availability topology, its own cancellation surface, and its own failure modes — but the reservation domain must be one model so the platform is operable as one system.

Symloop's position from the architecture review: unify the reservation state machine, isolate the vertical-specific rules behind a clean interface, and never allow vertical divergence to leak into the operator console or the financial-reconciliation path.

Consumer client — a search-and-book surface where the reservation flow is vertical-aware but the domain language underneath is identical across verticals. Consumers see three categorically different booking experiences because the ergonomics are different; the underlying reservation, the underlying confirmation, and the underlying cancellation path are one code path. Strong locale discipline: every date, currency, number, and time-zone rendering is locale-owned, never ad-hoc.

Operator client — a role-scoped console for the supply side. Availability calendars, pricing rules, listing content, and incoming reservations are first-class objects. Operators see only the verticals they own. The console is engineered for non-technical operators working under time pressure — which is a different performance and error-surface profile than the consumer client, handled as a separate rendering context against the same domain.

Platform client — the platform-operations console for onboarding providers, moderating listings, resolving disputes, and generating reconciliation reports. The platform role never touches consumer or operator write paths — it reads the reservation history and writes only moderation and configuration. This boundary is enforced at the service layer, not at the UI.

Reservation domain — a single state machine with well-defined transitions: inquiry → held → confirmed → fulfilled or cancelled or refunded. Every transition emits an event that the financial-reconciliation pipeline and the notification pipeline consume independently. No business code is allowed to write reservation state by direct mutation; transitions go through the domain interface.

Payment abstraction — a payment gateway interface that isolates the domain from any specific processor. The platform talks to an internal payment contract; concrete processors live behind an adapter. Swapping a processor — or adding a second one for a new market — does not touch reservation logic.

Notification abstraction — an outbound-messaging interface on the same pattern: the domain emits events, the notification layer decides delivery channel (email, SMS, in-app) and format. The domain does not know how a confirmation reaches a consumer; it only knows one was confirmed.

Single reservation domain. One aggregate, one state machine, one audit trail. Vertical-specific behavior (night count vs. time slot vs. pickup/return) lives in policy objects that implement a common reservation interface, not in parallel codebases. This is the core decision that makes the marketplace operable.

Service-level role boundaries. Consumer, operator, and platform code paths share the same data but not the same write capability. Authorization is enforced at the service layer — the UI does not decide what a user can do; it discovers what the service allows. This keeps the trust model intact even when the UI changes.

Processor-agnostic payment contract. The reservation domain emits money-movement events against an internal contract. Whichever payment processor the market requires sits behind that contract as an adapter. Regional rollout does not mean rewriting the reservation engine; it means implementing one adapter.

Locale as a first-class citizen. Arabic RTL, French LTR, English LTR — the application is not a translated English codebase. Locale information flows through every layer: format, calendar, currency, timezone, sorting, validation. No surface of the product displays a locale-incorrect artifact.

Static-first SEO surface, dynamic-first booking surface. The public pages are statically generated at build time for SEO correctness and edge delivery. The booking flow is dynamic, authenticated, and isolated from the SEO pipeline. A search-engine crawler and a paying consumer never contend for the same resources.

Separate read and write infrastructures. Consumer reads, operator reads, and platform reads scale on different planes. Reservation writes go through a single-writer contract so state transitions remain deterministic under concurrent load. This is the boundary that keeps the marketplace correct when traffic spikes.