DoorDash System Design Interview

The DoorDash system design interview is one 45-to-60-minute round on a shared whiteboard, and it leans more pragmatic than the brand suggests. You are about as likely to design a single service, resilient Dasher payouts or the reviews and ratings system, as the whole three-sided marketplace. It is senior-weighted and used for leveling: new grads often skip a full design round, mid-level gets one that counts, and senior loops go deepest. Scope one service tightly, put real numbers on it, and make money idempotent so a retry never double-pays.

DoorDash's design round leans harder than its brand suggests on focused, service-level prompts. Design a resilient a Premium question system. Build the food rating and review service. Stand up the notification pipeline. The big marketplace exercise is real too, a three-sided marketplace with drivers on a live map, "design DoorDash" in sixty minutes, and it is the canonical prompt the round is built around. But the smaller, pragmatic systems show up at least as often, so the one you draw is as likely to be a single service as the whole platform.

So prep wider than the marquee prompt. Drill only "design Uber for food" and you are ready for one question and flat on the four DoorDash actually reaches for. Scope a single service tightly, put real numbers on it, make money idempotent so a retry never double-pays, and say cleanly how it bends under a dinner rush. Capacity math and a failure-and-recovery plan beat a sprawling diagram every time. Scope is the skill, on a marketplace box or a payout ledger alike.

The DoorDash angle

Name DoorDash's real systems as the shape of an answer, never as a codename you wave around. The dispatch brain candidates read about is DeepRed, reported as two layers. An ML layer predicts how an order plays out if it goes to a given Dasher. An optimization layer then makes the assignment across a whole region at once, sharded by geography and run asynchronously so it finishes in seconds. DoorDash's engineering blog walks through both layers in Using ML and Optimization to Solve DoorDash's Dispatch Problem. There the optimization step is a mixed-integer model that makes system-wide decisions for the whole marketplace. Canonical order state is described as living in an Order Management Service that drives the lifecycle from placed to delivered. Reference these as how DoorDash's architecture is built, defend the category when the interviewer has not heard the internal name, and you read like someone who has worked the problem.

Who gets the round, and how much it counts

DoorDash runs a dedicated design round, roughly 45 to 60 minutes, inside the virtual onsite, and it uses that round explicitly for leveling. The bar climbs hard with seniority. A new grad may not face a full architecture round at all, with the loop tilted toward coding and the Code Craft round instead. By senior it is a weighted, level-setting seat. Confirm your own schedule with your recruiter, since the decentralized, per-team process means the exact mix moves by org and by month.

• ~ New grad / E3. Light or skipped. The loop leans on the coding and Code Craft rounds over production-grade architecture.
• 1 Mid / E4. One design round that counts, weighted under the coding seats; a clean end-to-end answer you can defend is enough.
• 1+ Senior / E5+. A primary, level-determining signal, often with a deep dive into the joining team's stack; staff loops push architecture hardest.

What scales with level is the depth they hold you to. The prompt itself barely moves. Mid-level, a coherent design with the data flow and the obvious scaling levers lands the round. Senior and up, they want the engineer who has picked a partition key and said why, and chosen a consistency model for the money path. That same engineer knows what happens when one region's dispatch shard falls behind during a game-day surge. Because the debrief settles your level and your hire in the same conversation, a thin design showing is one of the cleaner ways a senior candidate gets landed a rung lower.

How DoorDash runs the hour

It is one prompt, on a shared virtual whiteboard, usually after the coding and behavioral seats. The reported cadence is steady. Clarify requirements and scope for the first stretch, get a high-level design on the board inside the opening 20 to 25 minutes, then spend the rest on trade-offs and one subsystem in depth. Senior candidates are expected to surface the requirements and the consistency, durability, and failure concerns themselves. Interviewers reportedly prize tight scoping and honest capacity math over a perfect picture, with a clear recovery plan as the close, so do not chase completeness at the cost of depth.

The shapes DoorDash asks most

Prompts cluster into a handful of recurring shapes. DoorDash doesn't publish how often each one comes up, so the chart below ranks them by how regularly candidates hit them, not by a precise percentage. Read the order, not the decimals. Order and dispatch is the canonical, expected box, but the pragmatic service-level shapes under it, reviews and resilient payments, together come up at least as often.

Read the chart as five distinct problems to learn. The ranking matters less than the shapes. Order and dispatch is the three-sided marketplace with an order state machine and food-ready timing at its center. Reviews is a write-read split with aggregation, anti-abuse, and a reward-credit tie back to payments. Resilient payments is exactly-once money under retries. ETA is a prediction problem posing as a tracking one. Dasher assignment is the optimization core of dispatch pulled out on its own. Bank hardest on order and dispatch, then split your time across payments and reviews, because the concrete prompts live there.

The DoorDash angle

One order fans out three ways the instant it lands. It tells the merchant to start cooking, asks logistics to find a Dasher, and keeps the consumer's live ETA ticking, all at once, each side seeing a different slice of the same truth. The state machine, placed to confirmed to preparing to ready-for-pickup to picked-up to delivered, is the spine every design hangs on. DoorDash interviewers go straight at the food-specific edges a ride-hailing answer skips: restaurant prep time, batching two orders from one kitchen onto one Dasher, the messy last hundred feet of parking and elevators. Lead with all three parties, not one happy path.

Running the hour

Run the time as an arc, spending the first few minutes scoping. Say what is in and out, name the read-versus-write skew, and put rough numbers down so every later choice visibly follows from them. Sketch the core entities and a thin API, then a high-level design you walk one requirement at a time. Leave real room to go deep, since the back half is where the senior verdict gets made. The cadence itself is universal, so the delivery framework lesson drills it end to end. This section stays on what DoorDash rewards on top.

The DoorDash angle

Name DoorDash's stack where it earns a place, because the person across the table likely runs it. DoorDash moved off a Python monolith to Kotlin and gRPC services using the strangler-fig pattern. It adopted Kafka around 2019, after RabbitMQ failures knocked over checkout and dispatch. Cassandra serves as a primary store at scale, with CockroachDB behind the configuration platform. Money is the place to be precise: a charge or payout has to be idempotent, meaning running it twice writes the same result once, backed by a ledger and reconciliation rather than hope. ETA is genuinely an ML serving problem at DoorDash, reported as having grown from tree-based models to a mixture-of-experts neural net with probabilistic forecasts. Drop these where they fit, gloss the category in plain words, and never reach for a brand as decoration.

The worked designs

Five designs, one per distinct shape, chosen to map onto DoorDash's actual prompts and its real architecture rather than a generic food-delivery template. Start with order and dispatch, since it is the canonical box and the marketplace frame the other four borrow from.

Each design assumes the fundamentals from the System Design course. The scaling playbook covers reads and writes, and the toolbox covers when to reach for Kafka, a key-value store, a cache, or a search index. These pages stay on the DoorDash-flavored design itself rather than re-teaching the mechanics.

Common questions