Back to Notes

DDIA Interview Map

DDIA Interview Map

How to read Designing Data-Intensive Applications as HLD/System-Design interview fuel — not as a textbook to finish. Maps each chapter to the interview lever it unlocks, the design problem to pair it with, and a cheap hands-on experiment. Links into [[synthesis/Job Switch Hub]] and [[synthesis/Interview Prep Hub]].

Scope: DDIA = HLD depth. It does not cover LLD (OOD, design patterns, SOLID) — keep that a separate track. Practical skill comes from building small, not reading.

Reading protocol (per chapter)

  1. One chapter / week, paced to the SD half of the [[project_dsa_sd_curriculum|26-week curriculum]]. Don't binge.
  2. Active loop: read → vault note (table + Mermaid diagram) → 3-5 flashcard Qs → end with an "Interview Trade-Offs" block (decision + cost, defendable out loud).
  3. Pair with a design problem that uses the concept (see map below).
  4. Hands-on experiment (~1-2 hrs): spin it up in Docker, break it, log result in System Design/DDIA/.

Chapter → interview lever → design pairing → experiment

DDIA 2nd edition (2025) chapter layout.

DDIA chInterview leverPair with design problemHands-on experiment
1 Trade-Offs in Data Systems ArchitectureOLTP vs OLAP, warehouse vs lake, system-of-record vs derived, cloud vs self-host, distributed vs single-node"...and the business needs dashboards" follow-up on any designPostgres + read replica; watch a heavy aggregate query
2 Defining Nonfunctional Requirementslatency p50/p99/tail, reliability & fault tolerance, scalability, shared-nothing, maintainability — the framing for every design introState NFRs first on any design; social-network home timeline (fan-out on read vs write)Load-test an endpoint, plot p99 vs throughput
3 Data Models & Query Languagesrelational vs document vs graph, normalization, star schema, event sourcing / CQRS"which DB?" / social graph / analytics schemaModel same data in Postgres vs MongoDB vs a graph DB
4 Storage & RetrievalLSM-tree vs B-tree, column-oriented storage, secondary indexes, vector embeddingsWrite-heavy ingestion (metrics/logs); search / vector retrievalCompare insert throughput B-tree vs LSM store
5 Encoding & Evolutionschema evolution, Protobuf/Avro vs JSON, REST vs RPC, event-driven dataflowAPI versioning / backward + forward compatibilityEvolve an Avro/Protobuf schema, test old↔new compat
6 Replicationsingle-leader / multi-leader / leaderless, sync vs async, replication lag, conflict resolutionRead-heavy feed; multi-region writesPostgres primary + replica, induce + measure lag
7 Shardingkey-range vs hash partitioning, hot spots, rebalancing, request routing, local vs global secondary indexesURL shortener, distributed KV storeHash vs range partition a dataset, find the hot key
8 TransactionsACID, isolation levels, snapshot isolation, write skew & phantoms, 2PL / SSI, 2PCPayments, inventory, bookingReproduce dirty/phantom reads across isolation levels
9 The Trouble with Distributed Systemsunreliable networks, unreliable clocks, process pauses, distributed locks & fencing tokens, Byzantine faults"what if a node dies mid-write / GC-pauses?" failure-firstKill a node mid-op; demo fencing token need
10 Consistency & Consensuslinearizability, cost of linearizability (CAP), logical clocks, consensus (Raft/Paxos), coordination servicesLeader election, distributed lock, config storeRun etcd/ZooKeeper, observe leader election
11 Batch ProcessingMapReduce, dataflow engines, joins & grouping, ETL, ML servingAnalytics pipeline, batch recommendationSpark job: distributed join + aggregate
12 Stream Processinglog-based brokers (Kafka), CDC, stream joins, windowing/time, exactly-onceNews-feed fan-out, notifications, real-time analyticsKafka producer/consumer; CDC from Postgres via Debezium
13 A Philosophy of Streaming Systemsdata integration, unbundling databases, designing apps around dataflow, end-to-end correctnessDesigning around dataflow; syncing derived dataWire a stream → materialized view
14 Doing the Right Thingprivacy, bias/discrimination, surveillance, data ethics & lawRarely a core question — good senior maturity signalReading only

Integration with weekly prep

Each SD week: 1 DDIA chapter + 1 design problem that exercises it + 1 experiment. The chapter concept must end up as a spoken argument in a mock, not passive notes. Record verdicts in the Weekly Tracker; surface SD readiness in [[synthesis/Job Switch Hub]].

Pacing guardrail

DDIA 2nd ed = 14 chapters ≈ 14 weeks at 1 ch/wk (chs 13-14 are lighter/skimmable, so ~12 weeks of heavy reading) — fits the SD half of the curriculum. DSA stays the primary gate; DDIA is the depth layer that makes SD answers senior-grade. Don't let it crowd algorithm reps.

Highest interview ROI: chs 2 (NFRs), 6 (Replication), 7 (Sharding), 8 (Transactions), 10 (Consensus), 12 (Stream Processing). If time-boxed, front-load these.

Chapter notes

  • [[System Design/DDIA/1. Trade-Offs in Data Systems Architecture]] — OLTP/OLAP, warehouse vs lake, ETL/ELT, HTAP, system-of-record vs derived, cloud vs self-host, cloud-native (storage/compute split), distributed vs single-node, microservices/serverless, cloud vs HPC fault model, data minimization & law (complete — only book summary skipped)
  • [[System Design/DDIA/2. Defining Nonfunctional Requirements]] — functional vs nonfunctional, home-timeline case study, fan-out on write vs read, materialized views, throughput vs response time + queueing, metastable failure (retry storms / backoff / load shedding / backpressure), latency vs service time, percentiles & tail latency (p50/p95/p99), tail-latency amplification, SLO/SLA, reliability (fault vs failure, SPOF, chaos engineering, HW/SW/human faults), scalability (shared-nothing, vertical vs horizontal), maintainability (complete — only book summary skipped)

More chapter notes link here as they're written.