hard
Design Ticketmaster
Sell 60 000 seats in ten minutes to a million people at once: hold a seat while someone pays, never sell it twice, and keep the site up when demand is a hundred times supply.
← All companies
Booking.com system design interview questions
4 questions on this site are reported in Booking.com software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: inventory, reservations, locking, queueing, thundering-herd, availability-search, double-booking, holds, calendar-sync, experimentation, hashing, statistics, stream-processing, analytics, fan-out, caching, saga, idempotency, external-inventory.
Run an AI mock Booking.com interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from Booking.com. It indicates where a question has been asked, nothing more.
Booking.com questions
hard
Design Airbnb
Search 7 M listings by place, dates and price, book a stay without ever selling the same night twice, and keep calendars in sync with hosts’ other platforms.
hard
Design an A/B Testing Platform
Run 500 experiments at once on 300 M users: sticky variants in microseconds, exposure logging, and confidence intervals teams can trust.
hard
Design a Flight Booking System
Answer 50 M searches a day from 20 slow, metered suppliers through a fare cache, then book seats you do not own, exactly once.
What the Booking.com round looks like
About an hour, though some candidates report 90 minutes. Prompts come from the travel business: hotel availability and search, the booking flow, or payments work such as charging a card in scheduled instalments or screening cards for fraud.
What it is reported to weigh
- Correctness on the booking path: no double booking, and payment steps that are safe to retry
- Search that can show slightly stale availability, kept apart from a booking that must be exact
- Calls to outside systems, such as payment or fraud providers, and what happens when one fails
The common mistake
Treating search and booking as one problem. Search can afford to be a little out of date but the booking and its payment cannot, and interviewers are reported to probe how two guests are kept from the same room and how a failed step is retried.
From public interview guides and candidate reports, and Booking.com’s own interview guidance where it publishes any. Not endorsed by Booking.com. Formats change; treat it as a prior, not a promise.
How to prepare for the Booking.com system design interview
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in Booking.com interviews under different names.
- Design a URL Shortenerkey-generation · caching · cdn
- Design Slackreal-time · websockets · fan-out
- Design a Payment Systemconsistency · idempotency · ledger
- Design a News Feedfan-out · ranking · caching
- Design YouTubetranscoding · cdn · adaptive-bitrate
- Design Google Mapsgeospatial · routing · graphs
- Design a Matchmaking Systemqueues · scheduling · latency
- Design Ubergeospatial · matching · streaming
- Design a Notification Systemfan-out · multi-channel · idempotency
- Design Google Docscrdt · operational-transform · websockets
- Design an LLM Inference Servicegpu-batching · streaming · scheduling
- Design ChatGPTstreaming · tool-calling · context-management
- Design a Distributed Cacheconsistent-hashing · eviction · replication
- Design a Web Crawlerfrontier · politeness · dedupe
- Design a Rate Limiteralgorithms · counters · redis
- Design Dropboxchunking · dedupe · sync
- Design Search Autocompletetries · ranking · caching
- Design an Ad Click Aggregatorstream-processing · windowing · exactly-once
- Design a Distributed Job Schedulerscheduling · leases · idempotency
- Design a Stock Exchangeorder-book · determinism · event-sourcing
- Design a Project-to-Contractor Matching Systemrecommendations · ranking · marketplace
- Design Instagrammedia-pipeline · object-storage · fan-out
- Design WhatsApppersistent-connections · store-and-forward · end-to-end-encryption
- Design Netflixcdn · proactive-caching · adaptive-bitrate
- Design Yelpgeospatial-index · search · ranking
- Design a Real-Time Leaderboardsorted-sets · ranking · sharding
- Design a Distributed Key-Value Storeconsistent-hashing · quorum-replication · conflict-resolution
- Design a Unique ID Generatorid-generation · clocks · leases
- Design LeetCodesandboxing · job-queue · untrusted-code
- Design a Distributed Message Queueappend-only-log · partitioning · replication
- Design a Metrics and Monitoring Systemtime-series · compression · cardinality
- Design Tindergeo-sharding · recommendations · bloom-filters
- Design Redditcomment-trees · voting · ranking
- Design DoorDashstate-machine · dispatch · eta-prediction
- Design AWS Step Functionsworkflow-orchestration · event-sourcing · durable-timers
- Design Apache Airflowworkflow-orchestration · dag-scheduling · backfills
- Design Zapierworkflow-orchestration · polling · webhooks
- Design an Online Auctioncontention · compare-and-set · durable-timers
- Design Live Commentsbroadcast · pub-sub · sse
- Design a Top-K Heavy Hitters Serviceheavy-hitters · count-min-sketch · sliding-windows
- Design Zoomwebrtc · sfu · real-time-media
- Design Google Searchinverted-index · scatter-gather · tail-latency
- Design Spotifyprefetching · licensing · offline
- Design Gmailsmtp-ingress · spam-filtering · per-user-sharding
- Design Amazonshopping-cart · inventory · caching
- Design a Large File Distribution Systempeer-to-peer · chunking · bandwidth
- Design a Recommendation Systemrecommendations · ranking · vector-search
- Design a Distributed Lock Serviceconsensus · leases · fencing-tokens
- Design an Object Storage Serviceerasure-coding · range-partitioning · durability
- Design Google Calendarrecurrence · time-zones · fan-out
- Design a Code Deployment Systemdeployment · canary · reconciliation
- Design a Distributed Logging Systemlog-aggregation · inverted-index · tiered-storage
- Design Twitchlive-video · low-latency · transcoding
- Design a Price Trackeradaptive-scheduling · change-detection · time-series
- Design Stravageospatial · async-pipeline · spatial-matching
- Design Post Searchsearch · real-time · privacy
- Design Figmamultiplayer · last-writer-wins · websockets
- Design a Load Balancerload-balancing · networking · consistent-hashing
- Design a RAG Systemrag · vector-search · hybrid-search
- Design a CDNcdn · anycast · tiered-cache
- Design an API Gatewayapi-gateway · authentication · control-plane
- Design a Social Graphgraph · sharding · in-memory
- Design an Ad Serving Systemauctions · budget-pacing · ranking
- Design GitHubgit · replication · quorum
- Design Venmoledger · sharding · hot-keys
- Design a Multiplayer Game Backendreal-time · udp · game-servers
- Design TikTokshort-video · prefetch · session-ranking
- Design Google Newsclustering · ingestion · ranking
- Design GitHub Copilotlatency-budget · cancellation · prefix-caching
- Design Nearby Friendsreal-time · pub-sub · fan-out
- Design a Fraud Detection Systemfraud · feature-store · stream-processing
- Design Pastebinobject-storage · expiry · caching
- Design a Webhook Delivery Systemwebhooks · retries · isolation
- Design Pinterestrandom-walks · visual-search · deduplication
- Design a Vector Databasevector-search · ann-indexes · quantisation
- Design a Content Moderation Systemmoderation · perceptual-hashing · review-queues
- Design Robinhoodmarket-data · order-management · ledger
- Design a Container Orchestratorscheduling · reconciliation · consensus
- Design Discordreal-time · fan-out · actors
Questions people ask about the Booking.com system design interview
What system design questions does Booking.com ask?
Questions reported in Booking.com system design interviews include Ticketmaster, Airbnb, A/B Testing Platform and Flight Booking System. Between them they test inventory, reservations, locking, queueing, thundering herd and availability search. The reports come from public interview guides and candidate accounts, not from Booking.com, so practise the patterns rather than memorising one list.
What is the Booking.com system design interview like?
About an hour, though some candidates report 90 minutes. Prompts come from the travel business: hotel availability and search, the booking flow, or payments work such as charging a card in scheduled instalments or screening cards for fraud.
What does Booking.com look for in a system design interview?
Reports say the Booking.com round weighs 3 things. 1. Correctness on the booking path: no double booking, and payment steps that are safe to retry. 2. Search that can show slightly stale availability, kept apart from a booking that must be exact. 3. Calls to outside systems, such as payment or fraud providers, and what happens when one fails. Treating search and booking as one problem. Search can afford to be a little out of date but the booking and its payment cannot, and interviewers are reported to probe how two guests are kept from the same room and how a failed step is retried.
How do I prepare for the Booking.com system design interview?
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Ticketmaster: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (inventory, reservations, locking and queueing) with one more question each.