Hotel Booking System Design Deep Dive

Learn how to design a scalable Hotel Booking System from scratch. In this deep dive, we cover functional and non-functional requirements, APIs, database design, low-level design (LLD), high-level design (HLD), concurrency handling, room inventory management, booking workflow, payment integration, caching, distributed locking, event-driven architecture, scalability, and common interview follow-up questions. This tutorial is ideal for system design interview preparation for SDE-2, Senior Software Engineer, and Staff Engineer roles.

System Design HLD Approach to solve Free

Introduction

Welcome to this Booking.com Hotel Booking System Design Tutorial. In this tutorial, we will design a scalable Hotel Booking platform from scratch using a structured High-Level Design (HLD) approach.

The goal of this tutorial is not to memorize an architecture. Instead, you'll learn how to think like a senior software engineer and approach any System Design interview in a structured manner.

What Will We Build?

We will design a system similar to Booking.com where users can:

  • Search hotels using multiple filters.
  • View hotel details and room availability.
  • Book hotel rooms.
  • Make online payments.
  • Receive booking confirmations.
  • Cancel bookings and process refunds.

What Will You Learn?

  • How to gather requirements before designing.
  • How to identify core services.
  • How to design APIs.
  • How to draw High-Level Architecture.
  • How to choose the right database.
  • When and why to use Redis, Kafka and Elasticsearch.
  • How to design for scalability.
  • How to handle failures such as payment failures and double booking.
  • How to explain design trade-offs like a senior engineer.

Our System Design Framework

Throughout this tutorial, we will follow the same framework that can be applied to almost every High-Level Design interview.

  1. Understand Requirements
  2. Design APIs
  3. High-Level Architecture
  4. Request / Data Flow
  5. Data Storage
  6. Scalability
  7. Reliability & Failure Handling
  8. Trade-offs & Design Decisions
Interview Mindset

There is no single correct architecture. Every design decision depends on the requirements.

As we go through each step, we'll answer three questions:

  • Why are we making this decision?
  • What problem does it solve?
  • What trade-offs are we accepting?
By the end of this tutorial, you'll not only understand how to design a Booking.com-like Hotel Booking System, but you'll also have a reusable framework that can be applied to other System Design problems such as Uber, Amazon, WhatsApp, Food Delivery, Payment Systems, and many more.
Required Free

Introduction booking.com System design

Previous: None Next Resource
Notes

Step 1 - Understand Requirements.

Article Upcoming Required

Step 1 - Understand the Requirements

Before designing any system, the first responsibility of a software engineer is to understand what problem needs to be solved.

One of the biggest mistakes candidates make during interviews is immediately drawing Load Balancers, Microservices, Redis, Kafka, or Databases without understanding the actual requirements.

Golden Rule

Never start designing until you completely understand the problem.

Why Do We Ask Questions?

Every question helps remove uncertainty from the design. The clearer the requirements are, the better the architecture will be.

Question Why? If You Don't Ask...
What are the core features? Defines the scope of the system. You may waste time designing features that aren't required.
What is the user journey? Helps understand how requests flow through the system. Services may be designed in the wrong order.
What features are out of scope? Keeps the discussion focused. You may spend interview time on unnecessary components.

Functional Requirements

For our Booking.com Hotel Booking System, let's assume the interviewer confirms the following requirements.

  • Users can search hotels using different filters.
  • Users can view hotel and room details.
  • Users can check room availability.
  • Users can book available rooms.
  • Users can make online payments.
  • Users receive booking confirmation.
  • Users can cancel bookings.
  • Refunds are supported for eligible bookings.

Non-Functional Requirements

Functional requirements tell us what the system should do. Non-functional requirements tell us how well it should perform.

Question Why Ask? Impact on Design
Peak Traffic / QPS? Determines expected load. Helps decide whether a single server is enough or distributed architecture is required.
Read-heavy or Write-heavy? Understand traffic pattern. Helps decide caching strategy and database optimization.
Latency Requirement? Expected response time. May require Redis, CDN or optimized indexing.
Consistency Requirement? Determines data correctness expectations. Strong consistency is required to prevent double booking.
Single Region or Global? Determines deployment strategy. May require CDN, Geo Replication and Multi-region deployment.

Assumptions for This Tutorial

Daily Active Users 20 Million
Peak Requests 200,000 Requests / Second
Traffic Pattern Read Heavy (Search dominates Booking)
Response Time Less than 200 ms for Search
Consistency Strong consistency required for Booking & Payment
Deployment Global
Conclusion

We now have a clear understanding of both the business requirements and the expected scale of the system.

Based on these requirements, the next step is to identify how clients will communicate with our system by designing the APIs.

Continue Resource 0% complete

Step 2 - Design APIs.

Article Upcoming Required

Step 2 - Design APIs

Once the requirements are clear, the next step is to define how the client communicates with our system.

APIs act as the contract between the client (Web, Mobile, Partner APIs) and the backend services.

Why Design APIs Before Architecture?

Before deciding how many services we need or which database to use, we must first understand what operations the system needs to support. APIs help us identify the responsibilities of different services.

Core APIs

API Description Reason
GET /hotels/search Search hotels using filters. This is the starting point of the booking journey.
GET /hotels/{hotelId} View hotel details. User selects a hotel before making a booking.
GET /hotels/{hotelId}/availability Check available rooms. Booking should only be allowed if rooms are available.
POST /bookings Create a booking. Creates a new booking resource.
POST /payments Initiate payment. Payment is a separate business capability.
GET /bookings/{bookingId} Fetch booking details. User can check booking status.
DELETE /bookings/{bookingId} Cancel booking. Releases room inventory and may trigger a refund.

Example Search API

GET /hotels/search

Query Parameters

city=Goa
checkIn=2026-08-01
checkOut=2026-08-05
guests=2
priceMin=1000
priceMax=5000
rating=4
sort=price
page=1
size=20
Why GET?
  • Search is a read-only operation.
  • GET is idempotent.
  • Supports browser and CDN caching.
  • URLs can be bookmarked and shared.

Can Search Use POST?

Yes, but only when the search request becomes very large or contains complex nested filters. 

POST /hotels/search

{
    "cities": ["Goa","Mumbai"],

    "amenities": [
        "wifi",
        "pool",
        "spa",
        "parking"
    ],

    "price": {
        "min":1000,
        "max":5000
    }
}
Trade-off

Prefer GET whenever possible because it follows REST principles and supports caching. Use POST only if the filter object becomes too large or difficult to represent using query parameters.

Service Ownership

APIs also help us identify service boundaries.

Service Owned APIs
Search Service GET /hotels/search
GET /hotels/{hotelId}
Inventory Service GET /hotels/{hotelId}/availability
Booking Service POST /bookings
GET /bookings/{bookingId}
DELETE /bookings/{bookingId}
Payment Service POST /payments
Conclusion

We now know how clients interact with our system and have identified the major business capabilities.

Using these APIs, we can now design the High-Level Architecture and decide how different services communicate with each other.

Continue Resource 0% complete

Step 3 - Identify Core Services

Article Upcoming Required

Step 3 - Identify Core Services

Now that we have identified the APIs, the next step is to determine which business capabilities should be separated into independent services.

A common mistake is to randomly create microservices. Instead, services should be identified based on business responsibilities.

Golden Rule

One service should own one business capability. It should have a clear responsibility and own its own business logic.

How Do We Identify Services?

We look at the APIs and group similar operations together.

API Business Capability Service
GET /hotels/search Search Hotels Search Service
GET /hotels/{id} Hotel Details Hotel Service
GET /availability Room Availability Inventory Service
POST /bookings Create Booking Booking Service
POST /payments Payment Processing Payment Service
Notification Email / SMS Notification Service

Our Core Services

Service Responsibility
Search Service Search hotels using different filters.
Hotel Service Provide hotel information and room details.
Inventory Service Maintain room availability and inventory.
Booking Service Create, update and cancel bookings.
Payment Service Process payments and refunds.
Notification Service Send Email, SMS and Push Notifications.

Why Separate Them?

Service Why Separate?
Search Heavy read traffic and independent scaling.
Inventory Requires strong consistency and locking.
Booking Contains core business workflow.
Payment Integrates with external payment gateways.
Notification Runs asynchronously and should not block bookings.
Interview Tip

Don't create unnecessary microservices. Every service should exist because it owns a separate business capability, not because "microservices are popular."

Conclusion

We have identified all major services and their responsibilities.

In the next step, we'll connect these services together and design the complete High-Level Architecture of our Booking.com system.

Continue Resource 0% complete

Step 4 - Design High-Level Architecture

Article Upcoming Required

Step 4 - Design High-Level Architecture

We now know the business requirements, APIs and core services. The next step is to connect everything together and build the overall system architecture.

Goal

Show how requests travel through the system and how different services communicate with each other.

High Level Architecture


                    +----------------------+
                    |   Web / Mobile App   |
                    +----------+-----------+
                               |
                               |
                     HTTPS Request
                               |
                               ▼
                    +----------------------+
                    |    Load Balancer     |
                    +----------+-----------+
                               |
                               ▼
                    +----------------------+
                    |     API Gateway      |
                    +----------+-----------+
                               |
          --------------------------------------------------
          |          |          |          |               |
          ▼          ▼          ▼          ▼               ▼

 +----------------+  +----------------+  +----------------+
 | Search Service |  | Hotel Service  |  | Inventory Svc  |
 +----------------+  +----------------+  +----------------+
                              |
                              |
                              ▼
                      +----------------+
                      | Booking Service|
                      +----------------+
                              |
                              |
                     ---------------------
                     |                   |
                     ▼                   ▼

              +-------------+      +----------------+
              | Payment Svc |      | Notification   |
              +-------------+      +----------------+

Why Do We Need Each Component?

Component Responsibility Why is it Needed?
Load Balancer Distributes incoming traffic. Prevents a single server from becoming overloaded.
API Gateway Single entry point. Authentication, routing, rate limiting and request validation.
Search Service Search hotels. Search receives the highest traffic and should scale independently.
Hotel Service Hotel information. Manages hotel metadata, photos, descriptions and amenities.
Inventory Service Room availability. Ensures users only book available rooms.
Booking Service Booking workflow. Coordinates inventory, payment and booking confirmation.
Payment Service Payment processing. Integrates with external payment gateways.
Notification Service Email / SMS / Push Notifications. Sends booking confirmation asynchronously.

How Does a Booking Request Flow?

  1. User searches hotels.
  2. Search Service returns matching hotels.
  3. User opens hotel details.
  4. Inventory Service checks room availability.
  5. User clicks Book Now.
  6. Booking Service creates a pending booking.
  7. Payment Service processes payment.
  8. If payment succeeds, booking is confirmed.
  9. Notification Service sends confirmation email and SMS.

Why Not One Large Service?

Splitting responsibilities into different services allows:
  • Independent deployment.
  • Independent scaling.
  • Better fault isolation.
  • Clear ownership.
  • Easier maintenance.

Trade-off

Benefit
  • Better scalability.
  • Independent deployments.
  • Improved fault isolation.
Trade-off
  • More network calls.
  • Higher operational complexity.
  • Distributed transactions become difficult.
  • Monitoring becomes more challenging.
Conclusion

We now have a complete high-level architecture and understand how the major services interact with each other.

In the next step, we'll dive deeper into how a booking request flows between these services, including inventory checks, payment processing, booking confirmation and notifications.

Continue Resource 0% complete

Step 5 - Design the Request Flow

Article Upcoming Required

Step 5 - Design the Request Flow

We have identified all the services and connected them together. Now let's understand how a booking request travels through the system.

Goal

Explain the complete lifecycle of a booking request, from hotel search until booking confirmation.

Complete Booking Flow


User

↓

Search Hotel

↓

Search Service

↓

Hotel Service

↓

Inventory Service

↓

Booking Service

↓

Payment Service

↓

Booking Confirmed

↓

Notification Service

↓

Email / SMS Sent

Step-by-Step Flow

Step Description Why?
1 User searches hotels. Start of the booking journey.
2 Search Service returns matching hotels. Display hotels based on filters.
3 User opens hotel details. User wants to view rooms and prices.
4 Inventory Service checks room availability. Prevent showing unavailable rooms.
5 User clicks Book Now. Booking process starts.
6 Booking Service validates request. Verify dates, room availability and user details.
7 Inventory Service temporarily locks the room. Prevent double booking while payment is in progress.
8 Payment Service processes payment. Collect payment before confirming booking.
9 Booking Service confirms booking. Create permanent booking record.
10 Inventory Service decreases available room count. Room should no longer be available.
11 Notification Service sends Email and SMS. Inform the customer about successful booking.

What Happens if Payment Fails?

  1. Payment Service returns failure.
  2. Booking is not confirmed.
  3. Inventory lock is released.
  4. Room becomes available again.

What Happens if Two Users Book the Last Room?

Both requests reach the Booking Service almost at the same time.

  • User A locks the inventory first.
  • User B waits or receives "Room Unavailable".
  • Only one booking succeeds.

We'll discuss the locking mechanism in a later step.

Why Is This Flow Important?

During interviews, the interviewer wants to understand:

  • Which service calls which service?
  • Which calls are synchronous?
  • Which operations should happen asynchronously?
  • Where failures can occur?
  • Which service owns each responsibility?
Conclusion

We now understand how requests move through our system and how different services collaborate to complete a booking.

The next step is deciding where each service stores its data, and why we choose technologies like PostgreSQL, Redis, Elasticsearch and Kafka.

Continue Resource 0% complete

Step 6 - Design Data Storage

Article Upcoming Required

Step 6 - Design Data Storage

At this stage, we know how requests flow through the system. Now we need to decide where each service stores its data.

Goal

Choose the right storage technology based on the business requirements rather than popularity.

Golden Rule

Every service owns its own data.

This prevents tight coupling and allows each service to evolve independently.

Storage Selection

Service Technology Reason
Search Service Elasticsearch Supports full-text search, filtering, sorting and geo search.
Hotel Service PostgreSQL Hotel metadata changes infrequently and requires relational storage.
Inventory Service PostgreSQL Requires strong consistency to prevent overbooking.
Booking Service PostgreSQL Booking data requires ACID transactions.
Payment Service PostgreSQL Financial data requires strong consistency and transactional guarantees.
Notification Service Kafka (Events) Notifications can be processed asynchronously.

Where Should Redis Be Used?

Use Case Reason
Popular Hotel Search Avoid repeated database queries.
Frequently Viewed Hotels Reduce latency.
Session Data Fast read/write operations.
Rate Limiting Redis counters are extremely fast.

Where Should Kafka Be Used?

Event Consumer
Booking Confirmed Notification Service
Payment Completed Analytics Service
Booking Cancelled Refund Service
Inventory Updated Search Index

Why Elasticsearch?

Problem

Searching hotels by city, price, rating, amenities and location using SQL becomes expensive as data grows.

Solution

Elasticsearch is optimized for filtering, ranking, geo search, autocomplete and full-text search.

Why PostgreSQL?

Problem

Booking and payment cannot tolerate inconsistent data.

Solution

PostgreSQL provides ACID transactions, row locking and strong consistency.

Trade-offs

Technology Benefit Trade-off
Redis Very low latency Cache invalidation becomes difficult.
Kafka Loose coupling and scalability. Eventual consistency.
PostgreSQL Strong consistency. Horizontal scaling is harder.
Elasticsearch Excellent search performance. Need to synchronize data from primary database.
Conclusion

We have selected the appropriate storage technology for every service based on its responsibility.

The next step is to understand how this architecture scales to millions of users.

Continue Resource 0% complete

Step 7 - Scalability.

Article Upcoming Required

Step 7 - Design for Scalability

Our architecture works correctly, but can it handle millions of users? Scalability is about ensuring the system continues to perform as traffic grows.

Goal

Design the system so it can support increasing users, requests and data without major architectural changes.

Possible Bottlenecks

Problem Possible Impact
Too many search requests Search becomes slow.
Database receives millions of reads Database CPU becomes overloaded.
One Booking Service instance Cannot handle peak booking traffic.
Large number of notification requests User has to wait for Email/SMS.

Scaling Strategies

Component How We Scale Reason
Load Balancer Add more application servers. Distribute incoming traffic.
Search Service Horizontal Scaling Search traffic is read-heavy.
Booking Service Multiple Stateless Instances Handle concurrent bookings.
Redis Cluster Mode Handle more cache requests.
PostgreSQL Read Replicas Reduce read pressure on primary database.
Kafka More Partitions & Consumers Increase asynchronous processing capacity.
Elasticsearch Add Data Nodes Distribute search queries.

Scaling the Search Service

Search receives the highest traffic. Therefore it should be scaled independently. 


User

↓

Load Balancer

↓

Search Service

Search Service

Search Service

↓

Elasticsearch Cluster

Scaling the Booking Service

Booking is write-heavy and requires strong consistency. 


Load Balancer

↓

Booking Service

Booking Service

Booking Service

↓

Primary PostgreSQL

↓

Read Replicas

Scaling Notifications


Booking Confirmed

↓

Kafka

↓

Notification Worker

↓

Email

↓

SMS
The Booking Service immediately returns success to the user. Sending Email and SMS happens asynchronously.

Traffic Spike Example

Assume New Year's Eve causes booking traffic to increase 10x.

Challenge Solution
High Search Traffic Scale Search Service horizontally.
Database Read Pressure Redis + Read Replicas.
Large Number of Emails Kafka + Multiple Notification Workers.
Booking Requests Add Booking Service instances behind Load Balancer.

Trade-offs

Decision Benefit Trade-off
Horizontal Scaling Supports more traffic. More infrastructure to manage.
Read Replicas Reduce read load. Replication lag.
Redis Fast response. Cache invalidation.
Kafka Asynchronous processing. Eventual consistency.
Conclusion

Our architecture can now scale horizontally, support traffic spikes, and efficiently process millions of requests.

The next step is to understand how our system behaves when failures occur, such as payment failures, database crashes, or duplicate booking requests.

Continue Resource 0% complete

Step 8 - Reliability & Failure Handling

Article Upcoming Required

Step 8 - Reliability & Failure Handling

A scalable system is not enough. A production system must continue working even when some components fail.

This is where senior engineers differentiate themselves. Instead of assuming everything works perfectly, they think about what happens when things go wrong.

Goal

Design a system that can recover from failures while protecting business data and providing a good user experience.

Common Failure Scenarios

Scenario Problem Solution
Payment Failed User payment was unsuccessful. Release inventory and cancel pending booking.
Payment Succeeded but Booking Failed User paid but booking wasn't confirmed. Use Saga Pattern or Compensation to refund the payment.
Booking Succeeded but Notification Failed User never received confirmation email. Retry asynchronously using Kafka.
Redis Down Cache unavailable. Fallback to Database.
Database Down Cannot process bookings. Fail gracefully and return meaningful error.
Kafka Down Events cannot be published. Retry or use Outbox Pattern.

Double Booking Problem

Suppose only one room is available. Two users click Book Now at exactly the same time. 


User A

↓

Book Room

                Room #101

User B

↓

Book Room
Without proper locking, both users may successfully book the same room.
Solution
  • Optimistic Locking
  • Pessimistic Locking
  • Atomic Inventory Update

Duplicate Requests

User clicks the payment button multiple times. 


Click

Click

Click
Use an Idempotency Key. The server processes the request only once, even if multiple identical requests arrive.

Retry Strategy

Operation Retry?
Email Yes
SMS Yes
Payment Only if idempotent.
Booking Creation Only if idempotent.

Useful Design Patterns

Pattern When to Use
Retry Temporary failures.
Circuit Breaker Prevent cascading failures.
Saga Pattern Distributed transactions.
Outbox Pattern Reliable event publishing.
Idempotency Prevent duplicate processing.

Interview Thinking

Whenever the interviewer asks:
  • What if payment fails?
  • What if Kafka is unavailable?
  • What if Redis crashes?
  • What if two users book simultaneously?
  • What if the same request is sent twice?
Don't panic. Think: Detect → Recover → Keep Data Consistent

Trade-off

Decision Benefit Trade-off
Optimistic Locking High throughput. Retries may increase.
Pessimistic Locking No double booking. Lower concurrency.
Saga Pattern Distributed consistency. More implementation complexity.
Outbox Pattern Reliable event delivery. Additional storage and background processing.
Conclusion

Our Booking.com system is now scalable, fault tolerant, and capable of handling real-world production failures.

The final step is to summarize the architecture, explain the major design decisions, and discuss the trade-offs we made throughout the design.

Continue Resource 0% complete

Step 9 – Final Architecture Summary

Article Upcoming Required

Step 9 - Final Architecture Summary

We have now completed the design of our Booking.com Hotel Booking System. Let's summarize the complete architecture and the major design decisions.

Complete High Level Architecture


                          Users
                             │
                             ▼
                   +-------------------+
                   |   Load Balancer   |
                   +-------------------+
                             │
                             ▼
                   +-------------------+
                   |    API Gateway    |
                   +-------------------+
                             │
      ---------------------------------------------------------
      │            │             │             │              │
      ▼            ▼             ▼             ▼              ▼

+-------------+ +-------------+ +-------------+ +-------------+ +----------------+
|   Search    | |    Hotel    | | Inventory   | |  Booking    | |  Notification |
|   Service   | |   Service   | |   Service   | |   Service   | |    Service     |
+-------------+ +-------------+ +-------------+ +-------------+ +----------------+
      │              │               │               │
      │              │               │               ▼
      │              │               │       +---------------+
      │              │               │       | Payment Svc   |
      │              │               │       +---------------+
      │              │               │
      ▼              ▼               ▼

 Elasticsearch      PostgreSQL      PostgreSQL

                           Booking Database
                                PostgreSQL

Notification
      ▲
      │
    Kafka

Redis Cache
 ↑
 |
Search Service

Technology Summary

Technology Purpose Reason
Load Balancer Traffic Distribution Prevent server overload.
API Gateway Single Entry Point Authentication, Routing and Rate Limiting.
PostgreSQL Booking & Payment ACID Transactions and Strong Consistency.
Redis Caching Reduce response time and database load.
Elasticsearch Hotel Search Fast filtering, sorting and full-text search.
Kafka Async Communication Loose coupling and scalability.

Key Design Decisions

  • Separated business capabilities into independent services.
  • Used PostgreSQL for transactional consistency.
  • Used Elasticsearch for fast hotel search.
  • Used Redis to reduce database reads.
  • Used Kafka for asynchronous processing.
  • Used Inventory Service to prevent double booking.
  • Used Notification Service asynchronously.

Major Trade-offs

Decision Benefit Trade-off
Microservices Independent Scaling Operational Complexity
Redis Low Latency Cache Invalidation
Kafka Loose Coupling Eventual Consistency
SQL Database Strong Consistency Harder Horizontal Scaling
Elasticsearch Powerful Search Need Data Synchronization
How to Present This in an Interview
  1. Start with requirements.
  2. Define APIs.
  3. Identify services.
  4. Draw the architecture.
  5. Explain the booking flow.
  6. Choose storage technologies.
  7. Discuss scalability.
  8. Handle failure scenarios.
  9. Explain trade-offs.
  10. Ask if the interviewer wants a deeper dive into any component.
Congratulations
Continue Resource 0% complete

Bonus - Interview Deep Dive Questions

Article Upcoming Required

Bonus - Interview Deep Dive Questions

Completing the High-Level Design is only the beginning. Most interviewers spend the remaining time asking follow-up questions to understand your engineering decisions.

Remember

Every technology you introduce becomes a possible interview topic.

API Gateway

Possible Question Expected Discussion
Why API Gateway? Authentication, Routing, Rate Limiting, Logging.
Can clients call services directly? Possible, but increases coupling and security concerns.

Redis

Possible Question Expected Discussion
Why Redis? Reduce database reads and improve latency.
What if Redis crashes? Fallback to Database.
How will cache remain consistent? Cache Aside, TTL, Event Driven Cache Update.

PostgreSQL

Possible Question Expected Discussion
Why SQL? ACID Transactions.
Why not MongoDB? Bookings require strong consistency.
How will you scale PostgreSQL? Read Replica, Partitioning, Sharding.

Kafka

Possible Question Expected Discussion
Why Kafka? Asynchronous communication.
Why not REST? Loose coupling and better scalability.
What if Kafka is unavailable? Retry, Outbox Pattern.

Inventory Service

Possible Question Expected Discussion
How do you prevent double booking? Optimistic Locking / Pessimistic Locking.
Two users book simultaneously? Atomic inventory update.

Payment Service

Possible Question Expected Discussion
Payment succeeds but booking fails? Saga Pattern + Compensation.
Booking succeeds but payment fails? Release Inventory.
Duplicate payment request? Idempotency Key.

Search Service

Possible Question Expected Discussion
Why Elasticsearch? Filtering, Sorting, Full-text Search.
Search becomes slow? Redis Cache + More Elasticsearch Nodes.
Autocomplete? Elasticsearch Suggesters.

Scalability

Possible Question Expected Discussion
Traffic increases 10x? Horizontal Scaling.
Database becomes bottleneck? Redis + Read Replica.
Millions of notifications? Kafka + Multiple Consumers.
Interview Tip

After presenting your design, don't stop talking. Expect the interviewer to pick one component and ask: "Why did you choose this?" Every technology choice should have a business reason, not just a technical reason.

Continue Resource 0% complete

FAQ

Article Upcoming Required

Interview Deep Dive Questions

After you complete your High-Level Design, the interviewer will usually spend the remaining time asking deep-dive questions. These questions are designed to evaluate your engineering decisions, not your ability to memorize architecture diagrams.

Golden Rule

Every technology you introduce (Redis, Kafka, PostgreSQL, Elasticsearch, etc.) becomes a possible interview topic.

1. Why Redis?

Why does the interviewer ask this?

To verify whether you actually understand caching, or you are simply adding Redis because everyone uses it.

Expected Answer

Hotel search is a read-heavy operation. Instead of querying PostgreSQL repeatedly, frequently searched hotels are cached in Redis. This reduces latency and decreases database load.

Key Concepts
  • Cache Aside Pattern
  • TTL
  • Cache Invalidation
  • Hot Keys
Trade-off

Better performance, but cache consistency becomes more difficult.

Possible Follow-up Questions
  • What if Redis crashes?
  • How do you invalidate cache?
  • What data should never be cached?

2. Why Kafka?

Why does the interviewer ask this?

To understand whether you know asynchronous communication and event-driven architecture.

Expected Answer

Sending emails and SMS should not delay the booking response. Booking Service publishes an event to Kafka, and Notification Service processes it asynchronously.

Key Concepts
  • Producer
  • Consumer
  • Partition
  • Consumer Group
  • Ordering
Trade-off

Better scalability, but eventual consistency.

Possible Follow-up Questions
  • Why not REST?
  • What if Kafka is down?
  • How do you avoid duplicate events?

3. Why PostgreSQL?

Why does the interviewer ask this?

They want to know whether your database selection matches the business requirements.

Expected Answer

Booking and Payment require strong consistency. PostgreSQL provides ACID transactions, row locking and reliable transactional guarantees.

Key Concepts
  • ACID
  • Transactions
  • Isolation Levels
  • Indexes
Trade-off

Strong consistency, but horizontal scaling is harder than many NoSQL databases.

Possible Follow-up Questions
  • Why not MongoDB?
  • How do you scale PostgreSQL?
  • Read Replicas?
  • Sharding?

4. How do you prevent double booking?

Why does the interviewer ask this?

This is one of the most common Booking.com interview questions.

Expected Answer

Inventory must be updated atomically. Use Optimistic Locking, Pessimistic Locking, or Atomic SQL Update so that only one user can reserve the last available room.

Key Concepts
  • Optimistic Locking
  • Pessimistic Locking
  • Atomic Update
Possible Follow-up Questions
  • Which locking strategy would you choose?
  • What if payment fails after inventory is locked?
Interview Tip

Whenever the interviewer asks "Why did you choose this?" always structure your answer like this: 


Problem

↓

Solution

↓

Benefits

↓

Trade-offs

↓

Alternative Solutions
Continue Resource 0% complete

Related Tutorials

System Design Interviews: How to Approach Any Question from Scratch

Memorise this if you want to survive IT interviews

Related Learning Actions

Open Topic Learning