Distributed Systems · Developer
Kayak - Travel Metasearch.
A team-built, 3-tier travel metasearch and booking platform: a React client over Node/Express services (API gateway, user, search, booking) backed by MySQL, MongoDB, and Redis, with a separate Python AI service for chat, deal scoring, and bundles.
- Role
- Developer
- When
- 2025
- Stack
- Node.js, React, FastAPI, MySQL
- Scale
- 3 tiers client · services · data
3-tier · semantic cache3 tiersclient · services · data
Semantic cachefor LLM responses
3 storessplit by workload
Kafkaevent streaming
The problem
A Kayak-style metasearch site has to serve flights, hotels, and car rentals to clients, keep bookings transactionally correct, run analytics, and layer on AI recommendations, all without those concerns tangling together. The project's goal was a clean 3-tier distributed system: a client tier, a middleware tier of independent services, and a data tier split by job, with an AI service kept off to the side.
What it does
- A 3-tier architecture: a React client, a middleware tier of Node/Express services, and a data tier of MySQL, MongoDB, and Redis, each chosen for what it is good at.
- Middleware services behind an API gateway that handles JWT auth, rate limiting, and routing: a user service, a search service (MongoDB + Redis caching), and a booking service with transactional inserts and inventory decrements.
- Data split by purpose: MySQL for transactional bookings, billing, and listings; MongoDB for analytics, reviews, and event logs; Redis for caching search results.
- Kafka for event streaming between services, with an in-memory Kafka implementation behind the same interface so the team could develop independently before the real broker existed.
- A separate Python FastAPI AI service: a concierge chat agent, a deals-scoring background worker, plus bundles, price-analysis, watches, and quotes APIs, with a semantic cache for LLM responses and rule-based intent parsing that uses OpenAI only when available.
Impact
- Clean separation of concerns across three tiers, so transactional booking (MySQL), analytics (MongoDB), and caching (Redis) each use the right store instead of forcing one database to do everything.
- A semantic cache that returns a stored answer when a new query is similar enough (cosine > 0.85), cutting repeat LLM calls instead of re-asking the model every time.
- Designed for parallel team development: an interface-based Kafka client lets the system run on an in-memory queue locally and switch to a real broker by config alone.