Back to the work
Distributed Systems · Developer

Airbnb - Distributed Booking.

A team-built Airbnb-style booking platform that grew from a monolith into event-driven microservices: a React/Redux frontend over four Node services and a Python AI agent, talking through Kafka with MongoDB, and deployable on Kubernetes.

Role
Developer
When
2025
Stack
React, Redux, Node.js, MongoDB
Scale
6 services deployables
GitHub ↗
Airbnb - Distributed Booking previewmicroservices · Kafka · k8s
6 servicesdeployables
Kafkaevent bus
Kubernetesfull manifests
Ollamalocal LLM agent

The problem

An Airbnb-style app has clearly separable concerns, travelers, owners, properties, bookings, that fight each other inside a single codebase as it grows. The project's goal was to take a working monolith and re-architect it into independent services that communicate asynchronously, so a slow or failing service degrades the system instead of taking it down, and to make the whole thing deployable on Kubernetes.

What it does

  1. A React + Redux + Vite frontend (Tailwind) with feature slices for auth, properties, bookings, favorites, and the owner dashboard, talking to the backend over a small API layer.
  2. Four Node/Express microservices, traveler, owner, property, and booking, each with its own responsibility and MongoDB data, deployable independently.
  3. Kafka as the event bus: the booking service consumes booking-request and booking-update topics with consumer groups and retry-on-failure, so booking status stays consistent across services without synchronous coupling.
  4. A separate Python FastAPI agent service that uses LangChain with a local Ollama model to generate day-by-day travel itineraries as structured JSON.
  5. Packaged for both local and cluster runs: Docker Compose for development and a full set of Kubernetes manifests, with Playwright end-to-end tests, a Postman collection, and JMeter load testing.

Impact

  • Re-architected from a Lab 1 monolith into a Lab 2 event-driven microservices system, the evolution itself is the point: the same product, decomposed and made resilient.
  • The booking flow tolerates a missing Kafka broker (it logs and runs degraded) and retries failed messages, so async consistency does not become a single point of failure.
  • An AI concierge built as its own service rather than bolted onto the frontend, keeping the LLM dependency isolated behind a clean API.