Katkat
Back

Deep-dive a project architecture

DoorDashSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

An open-ended DoorDash software-engineer system-design screen: pick a real project and deep-dive its architecture end to end. Candidates draw the diagram, state invariants, walk read/write paths, justify storage and trade-offs, capacity-plan, cover reliability/security/observability with SLOs, recount a real incident, and propose a quantified 10x-traffic plan. Includes a full worked example built around a real-time delivery dispatch and live order-tracking service.

Question

Pick one of your recent, non-trivial projects and conduct a deep, end-to-end technical review. The interviewer will probe each layer, so be ready to whiteboard the system and defend your decisions. Address all of the following:

  1. Architecture diagram. Draw the end-to-end architecture: components, data stores, and the interfaces (REST/gRPC/streaming/WebSocket) between them.
  2. Data flow and invariants. Explain the major data flows and state the key correctness invariants the system must preserve (e.g. "exactly one active assignment per order").
  3. Read and write paths. Walk through the concrete read path and write path step by step, including caching, idempotency, and the latency budget for each.
  4. Data and storage. Describe the schema design and justify your storage choices (relational vs. NoSQL vs. cache vs. time-series/cold store), including partition/shard keys and indexes.
  5. Design decisions and trade-offs. Justify your major technology choices and call out the trade-offs you accepted (consistency vs. availability, push vs. poll, write-through vs. write-behind, etc.).
  6. Scalability, bottlenecks, and capacity planning. Give back-of-the-envelope numbers (QPS, message rates, storage), identify the bottlenecks, and explain how you'd capacity-plan for them.
  7. Consistency and reliability. Explain your consistency model, delivery guarantees, and reliability strategies (retries, idempotency, sagas, circuit breakers, DR/RPO/RTO).
  8. Security and access controls. Cover authN/authZ, service-to-service security, encryption in transit/at rest, PII handling, and compliance.
  9. Observability and SLAs/SLOs. Describe your logs, metrics, and traces, and define concrete SLIs/SLOs and the alerts/runbooks that back them.
  10. A significant incident or trade-off you handled. Describe a real production incident or hard trade-off decision, the root cause, and how you mitigated it.
  11. Two concrete improvements for a 10× traffic increase. Propose two specific changes that would let the system absorb 10× traffic, and quantify why they work.
  12. What you would redesign today and why. With hindsight, what would you change about the original design?

Use concrete numbers and real examples from your project; avoid hand-waving.