Start Here
A study guide for the 60-minute, discussion-based data systems design interview — architecting scalable, reliable data platforms and defending the trade-offs that hold them up.
The interview in one paragraph
This is a 60-minute, discussion-based session. You and the interviewer pick a data systems design scenario and go deep — how you'd build a scalable, reliable data platform, with a whiteboard available. The stated territory is data ingestion pipelines, change data capture (CDC) strategies, and the trade-offs between platforms and architectures — batch vs streaming, data lakes vs warehouses, build vs buy. There's no coding and no single correct answer. You're being measured on whether you can take an ambiguous "design us a data platform" prompt, structure it, and make—and defend—the handful of decisions that determine whether the platform is fast, correct, affordable, and maintainable.
Two things, above all: structured breadth (can you cover ingestion → storage → processing → serving → governance without getting lost) and defended trade-offs (can you choose batch or streaming, lake or warehouse, build or buy, and justify it against the requirements rather than by fashion). A candidate who says "it depends" and then actually makes the call, with reasons, beats one who lists options forever.
How it differs from a pipeline-build round
If your loop also includes a production-pipeline round, keep the two mentally separate — they reward different things, and this site has a guide for each.
| This guide — Data Systems Design | Companion — Production Data Pipelines | |
|---|---|---|
| Question | "Architect the platform. What are the pieces and why?" | "Build and operate this pipeline robustly." |
| Altitude | Platform / architecture — choosing between options | Pipeline / implementation — making one correct and reliable |
| Core skill | Requirements → sizing → architecture → defended trade-offs | Idempotency, late data, incremental processing, reconciliation |
| Signature topics | Ingestion, CDC strategy, batch vs streaming, lake vs warehouse, build vs buy | Orchestration, late-arriving data, validation & reconciliation |
They overlap at the edges (ingestion, CDC, batch vs streaming all appear in both), but at different depth. Where this guide brushes late-arriving data, reconciliation, or orchestration mechanics, it points you to the Production Data Pipelines guide rather than re-teaching them — so you can spend your time here on the architecture-level decisions.
The method that runs through everything
Because the interview rewards structure, the guide hangs off one repeatable six-step method. Run it on any scenario and you'll never be lost.
| Step | What you do |
|---|---|
| 1 · Requirements | Functional (which data, which consumers, which queries) + non-functional (volume/velocity/variety; freshness, availability, durability, consistency; budget; compliance). |
| 2 · Estimate | Back-of-envelope: throughput, bytes/day and retention → storage, read QPS, rough cost. |
| 3 · Architecture | Sketch sources → ingestion → storage → processing → serving, with orchestration and catalog/governance underneath. |
| 4 · Decisions / trade-offs | The named forks — batch vs streaming, lake vs warehouse vs lakehouse, CDC strategy, build vs buy — each justified against the requirements. |
| 5 · Deep dives | Follow the interviewer: CDC correctness, hotspots, exactly-once, schema evolution, failure. |
| 6 · Evolution | Scale 10×, failure and recovery, migration, cost control. |
Chapter 01 teaches the method in depth; Chapter 10 walks it end-to-end on a full scenario.
The topics they'll pull on
The interviewer has a handful of named levers. Expect real time on each; the guide gives each its own chapter.
- Data ingestion pipelines — how data gets into the platform at scale: sources, the log/queue backbone, connectors, delivery guarantees, schema handling. (Chapter 03.)
- CDC strategies — replicating source databases continuously: query-based vs log-based, snapshot-plus-stream, deletes and ordering. The topic that separates people who've integrated an OLTP source from those who haven't. (Chapter 04.)
- Batch vs streaming — the central processing fork, driven by the freshness SLA against cost and complexity. (Chapter 05.)
- Lakes vs warehouses vs lakehouses — where data lives and how it's queried. (Chapter 06.)
- Build vs buy — the decision every component triggers, and the one that reveals seniority fastest. (Chapter 07.)
Everything else — sizing (02), scalability & reliability (08), modeling & governance (09) — is the connective tissue that lets you answer those five like someone who has run a platform.
The guide in reading order
Five sections. The numbering is the order to read in.
Section A — Orient
| Chapter | Why |
|---|---|
| 01 · The Design Interview | How the format is graded, the six-step method in depth, and how to defend a trade-off and whiteboard a platform |
Section B — Building Blocks
| Chapter | Why |
|---|---|
| 02 · Requirements & Estimation | Pin requirements and SLAs; size the system so every later choice is grounded |
| 03 · Data Ingestion Pipelines | Ingestion architecture at scale — the log backbone, connectors, delivery guarantees, schema |
| 04 · Change Data Capture | CDC strategies compared, snapshot-plus-stream, deletes/ordering, landing to the platform |
Section C — The Big Trade-offs
| Chapter | Why |
|---|---|
| 05 · Batch vs Streaming | The central processing fork, with a decision matrix keyed to the freshness SLA |
| 06 · Lakes, Warehouses & Lakehouses | Where data lives; open table formats; a decision matrix on cost, openness, and workload |
| 07 · Build vs Buy | The TCO framework, the platform landscape, and a component-by-component scorecard |
Section D — Cross-Cutting Concerns
| Chapter | Why |
|---|---|
| 08 · Scalability & Reliability | Partitioning and skew, replication, fault tolerance, consistency, multi-region / DR |
| 09 · Modeling, Schema Evolution & Governance | Modeling choices, schema evolution, contracts, catalog/lineage, PII/compliance, cost |
Section E — Putting It Together
| Chapter | Why |
|---|---|
| 10 · The Design Session | The capstone — the method walked end-to-end on a full platform scenario |
| 11 · Practice Questions | ~30 Q&A with drill mode, each with the decision heuristic |
| 12 · Day-Of Tactics | The method, whiteboard moves, questions to ask, red flags. Reread morning of |
Study schedule
Three calibrations — the same paths are on the hub:
- A week: one section per day; on day 6 actually whiteboard the worked scenario in 10 out loud, on a timer.
- Two days: 00, 01, 02, the named topics and trade-offs (03, 04, 05, 06, 07), 10, drill 11, 12. Skim 08, 09.
- An evening: 01 (the method), 04 (CDC), the decision matrices in 05/06/07, and the framework in 10.
What winning looks like
You don't need to have built every platform in this guide. You need to be the candidate who:
- Pins requirements and rough sizing before drawing boxes — freshness SLA, volume, consumers, budget.
- Sketches a clean end-to-end architecture and can walk any layer of it.
- Makes the named trade-offs explicitly — batch vs streaming, lake vs warehouse, build vs buy — and defends each against the requirements.
- Has a real CDC story: knows why log-based beats query-based when completeness and deletes matter, and can land changes correctly.
- Talks about cost, lock-in, and operability, not just throughput — the marks of someone who has owned a platform.
- States what they'd revisit as the system scales, and where it would break first.
If you can do those six things in a flowing conversation, you're in. Turn to 01 · The Design Interview.