Distributed Systems · Builder
Travel Booking Platform.
A 14-service travel booking platform (flights, hotels, cars, deals, billing) built as a TypeScript monorepo: independently deployable services communicating over Kafka, polyglot storage across MongoDB and MySQL, a React client with i18n, and a Python AI concierge, all orchestrated on Kubernetes.
- Role
- Builder
- When
- 2026
- Stack
- TypeScript, Node.js, Kafka, MongoDB
- Scale
- 14 services independently deployable
14 services · Kafka · k8s14 servicesindependently deployable
Kafkaevent bus
MongoDB + MySQLpolyglot storage
Kubernetesorchestrated
The problem
A travel booking site spans separate domains, flights, hotels, cars, deals, billing, notifications, that each scale and fail differently. Cramming them into one service couples their deploys and their blast radius. The aim here was to push that separation as far as it sensibly goes: a set of small, independently deployable services that coordinate through events rather than direct calls, and to run the whole thing on Kubernetes.
What it does
- A TypeScript monorepo of 14 services: an API gateway, domain services for flights, hotels, cars, booking, billing, and users, plus notification, admin/analytics, a deals worker, an airport resolver, external adapters, a Python AI concierge, and a React/Vite client.
- Event-driven coordination over Kafka: services publish and consume domain events (for example deal.events) on consumer groups, so a booking or a deal propagates asynchronously instead of through synchronous service-to-service calls.
- Polyglot persistence, MongoDB and MySQL for different services' needs with Redis for caching, and shared TypeScript types via an internal @kayak/shared package so events and models stay consistent across services.
- Containerized per service with Kubernetes manifests, Nginx, and GitHub Actions for CI, CD, and Pages, with unit, end-to-end, and performance test suites.
Impact
- Each of the 14 services has its own Dockerfile and can be built, tested, and deployed on its own, so a change to billing never forces a redeploy of flight search.
- Coordinating through Kafka topics rather than direct calls means a slow or offline service catches up from the log instead of failing its callers.
- Shared types and a monorepo keep a 14-service system coherent: one place for the event schemas every service agrees on.