System Design Walkthroughs: Uber, DoorDash, Google Maps, Ticketmaster, Payments and Google Docs

Eight system design interview questions about location, scarce inventory, money and collaboration: Uber, DoorDash, Google Maps, Ticketmaster, a payment system, Google Docs, Google Drive and the parking lot question. These are the designs where correctness under concurrency gets tested hardest, so each walkthrough says which data must never be wrong and how the design keeps it right. For the full prep plan, see our system design interview guide.

How to run any of these in 45 minutes

1. Clarify for five minutes. Pin down the two or three features that matter, the scale (daily users, reads versus writes, data size) and the one non-functional requirement that dominates, usually latency, availability or correctness.
2. Estimate in two. Rough numbers decide the design: requests per second at peak, storage per year, bandwidth for media. Round hard and say your assumptions out loud.
3. Sketch the API and the data model. Three to five endpoints and the main tables or keys. This is where you show you know what has to be stored and how it will be read.
4. Draw the high-level design. Clients, load balancer, stateless services, the stores, caches, queues and the CDN. Walk one request end to end.
5. Spend fifteen to twenty minutes on the deep dive. Each walkthrough below names the part interviewers push on. Lead there before you are asked.
6. Close with trade-offs. What breaks first at ten times the load, what you would monitor, and what you chose not to build.

These four domains, location, inventory, money and collaboration, are where correctness is tested hardest, so say early which data must be strongly consistent. New to the format? Read what a system design interview is first.

At a glance: the hard part of each question

Location and marketplaces

Design Uber

Clarify: requesting a ride, matching a nearby driver, live location, ETA, pricing including surge, and the trip lifecycle. Payments are usually out of scope.

Core design: drivers send their location every few seconds to a location service that keeps an in-memory geospatial index, using geohashes, a quadtree or hexagonal cells, sharded by region; the dispatch service queries nearby available drivers, sends an offer and handles accepts and timeouts; a trip service runs the trip's state machine; an ETA service uses the road graph and current traffic.

Deep dive: the write rate of location updates (keep them in memory and do not persist every point synchronously), matching without assigning one driver to two riders (a compare-and-set on the driver's state), and surge pricing computed per cell from supply and demand in a stream.

Trade-offs: cell size against query cost, consistency against latency in dispatch, and how a region fails over without losing trips in progress.

Design DoorDash

DoorDash is a three-sided marketplace: customers, restaurants and couriers. Clarify the order lifecycle: browse menus, place and pay, the restaurant accepts and prepares, dispatch assigns a courier, tracking, delivery and payouts.

Core design: a menu and catalog service that is read-heavy and cacheable, with search; an order service with a state machine and idempotent APIs; a dispatch service; and location tracking much like Uber's.

Deep dive: dispatch. It predicts when food will be ready and how long travel takes, then assigns couriers so they arrive just in time, batching orders where it saves time; the assignment runs as an optimization every few seconds rather than per order. Keep order state consistent across services with a saga and compensating steps, and use an outbox so events are not lost. Plan for the dinner rush with autoscaling and queues.

Trade-offs: a better assignment against a faster one, and the cost of a wrong prep-time estimate, which is cold food or idle couriers.

Design Google Maps

Clarify: showing the map, searching for places, routes with ETAs and traffic, and turn-by-turn navigation, worldwide.

Core design: map tiles, pre-rendered images or vector tiles, are served by zoom level from a CDN; a geocoding service turns addresses into coordinates; a routing service searches a road graph; a traffic pipeline turns anonymized location data into speeds per road segment.

Deep dive: routing at scale. A plain shortest-path search on a continental graph is too slow, so systems partition the graph and precompute shortcuts for major roads (contraction hierarchies are a common technique), then use A* with live edge weights. ETAs blend historical patterns with live traffic, and navigation reroutes when conditions change.

Trade-offs: precomputation against freshness when traffic changes, and vector tiles, which use less bandwidth and render on the device, against raster tiles.

Inventory and money

Design Ticketmaster

Clarify: browsing events, the seat map, holding seats, purchase, and enormous spikes when a popular show goes on sale. The rule that cannot break: no seat sold twice. Holds expire after a few minutes.

Core design: an event and venue catalog that is cached; an inventory service that keeps each seat's state, available, held or sold, in a strongly consistent store; holds with expiry; payment; and a virtual waiting room that lets buyers into the purchase flow at a controlled rate.

Deep dive: double booking (a conditional update that only succeeds if the seat is still available, or a short lock with expiry), the waiting room (queue tokens, admission at a set rate, fairness, and protection against automated buying), and the surge itself (serve seat maps from cache and static content from the CDN, and apply backpressure before the database).

Trade-offs: strong consistency for inventory at the cost of availability during peaks, and counters for general admission, which are simpler than individual seats.

Design a payment system

Clarify: taking payment at checkout through a payment provider, recording it in a ledger, refunds and merchant payouts. Correctness matters more than speed: money must move exactly once.

Core design: the payment service accepts a payment request with an idempotency key, records a payment order, hands the card step to the provider's hosted page so card numbers never touch your servers, waits for the provider's confirmation, updates the order's state and writes double-entry ledger records; a daily job reconciles your records against the provider's settlement files.

Deep dive: idempotency (store each key with its result so retries return the same answer), the absence of a distributed transaction with the provider (a state machine, retries, status queries after timeouts, an outbox for events and reconciliation to catch the rest), and the ledger (append-only, double-entry, every transaction summing to zero).

Trade-offs: synchronous confirmation is simpler for the user, while asynchronous is more reliable; security and compliance push you toward tokens and the smallest possible scope for card data.

Collaboration and files

Design Google Docs

Clarify: real-time collaborative editing, cursors, comments, version history, permissions and whether offline editing is in scope.

Core design: clients connect over a WebSocket to a collaboration server that owns the document's session; edits travel as operations that the server orders, transforms and broadcasts; the document is stored as snapshots plus an operation log; cursors and presence are broadcast but not stored.

Deep dive: making concurrent edits converge. Operational transformation has a central server order operations and adjust each one against the others, and Google Docs is widely described as using it; CRDTs give each character a position that merges the same way everywhere, which suits offline editing at the cost of extra metadata. Route each document to one server with consistent hashing and plan its failover; build version history from periodic snapshots and a compacted log.

Trade-offs: the complexity of operational transformation against the memory overhead of CRDTs, and very large documents, which strain both.

Design Google Drive or Dropbox

Clarify: upload and download, sync across devices, sharing and permissions, versions and large files.

Core design: the client splits files into blocks of a few megabytes and hashes each block; only new or changed blocks are uploaded, and identical blocks are stored once; a metadata service records files, versions and their block lists in a relational database; blocks live in object storage; a notification service tells a user's other devices when to sync; sharing is an access-control list on the metadata.

Deep dive: sync conflicts (two devices edit offline, so keep both and create a conflicted copy), deduplication and compression, strongly consistent metadata alongside immutable blocks, and resumable uploads for large files on poor connections.

Trade-offs: block size against dedup efficiency and metadata volume, and storage cost against tiering old versions to cold storage.

The object-oriented outlier

Design a parking lot

This one is an object-oriented design question, not a distributed system, so the interviewer is judging your classes, not your shards. Our object-oriented design interview guide covers the format in depth.

Clarify: levels, spot types (compact, regular, large, accessible, electric charging), vehicle types, entry and exit gates, tickets, payment and display boards.

Core design: classes for the parking lot, level, spot, vehicle and its subtypes, ticket, payment and gate. Spot assignment and pricing are separate strategies, so a new rule (nearest spot first, or a weekend rate) does not change the core classes.

Deep dive: two cars at two gates asking for the same spot (assign spots atomically), a full lot, a lost ticket, and adding a new vehicle type without editing existing classes. Interviewers sometimes finish by asking how you would support reservations across hundreds of lots, which turns it back into a service design.

For the infrastructure underneath these designs, see system design building blocks, and for feeds, chat and video, the social, messaging and video walkthroughs.

Where CoPilot Interview fits

System design is a conversation, so the fastest way to improve is to say a design out loud and hear where it wobbles. CoPilot Interview is an AI interview assistant whose free AI mock interview can run a marketplace, payments or collaboration design question against your résumé and the job description, read it aloud, score your spoken answer out of ten and show a model answer. The free plan gives 15 minutes a day of live help in sessions of up to 15 minutes, with AI mock interviews included. For the live round itself, follow your employer's rules: many companies now state their policy on AI tools in the invitation, and design rounds are where interviewers most want to hear your own reasoning.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly.

Frequently asked questions

Which of these is most likely at a fintech or marketplace company?

Payment systems and Ticketmaster-style inventory questions come up often at fintech and e-commerce companies because they test correctness under concurrency. Ride-hailing and delivery companies favor location and dispatch questions.

How do I show I understand consistency without a lecture?

Point at the data that cannot be wrong, such as seat inventory, ledger entries or a driver's assignment, and say how your design keeps it correct: a conditional update, a lock with expiry, an idempotency key or reconciliation. Then say where eventual consistency is fine, such as ETAs or view counts.

Is the parking lot question really system design?

It is usually an object-oriented design question, judged on classes, responsibilities and extensibility. If the interviewer asks about many lots and reservations, it becomes a service design and the usual approach applies.

How should I handle a question I have never seen?

Map it to the closest pattern: anything with moving people or vehicles is a geospatial index plus dispatch, anything with scarce inventory is holds and conditional updates, and anything with money is idempotency plus a ledger. Then adapt the details.

Where are the old single-question pages?

Each of the eight walkthroughs that used to be a separate page now lives in a section of this page, and the old addresses redirect to the matching section.