Study Roadmap

1. Recall: explain the topic without notes.
2. Apply: solve a bounded design problem.
3. Stress: inject failures, scale, skew, and migration.
4. Defend: state a decision, rejected alternatives, and evidence that would change it.
5. Review: score the answer and repeat the weakest dimension.

Diagnostic before starting

Give yourself 45 minutes and design a durable notification platform. Record the session. Score it with the senior rubric. Do not study first; the result is your baseline.

Mark each topic from 0–4:

Score	Meaning
0	I cannot define it reliably.
1	I can explain the happy path.
2	I can compare alternatives and do basic sizing.
3	I can design failure handling, observability, and migration.
4	I can lead a senior deep dive, challenge assumptions, and connect it to the rest of the system.

Twelve-week track

Plan for five sessions per week: three 60–90 minute study/practice sessions, one 45-minute timed design, and one 30-minute review. Keep a decision journal with the prompt, assumptions, numbers, trade-offs, failure modes, and one improvement for the next answer.

Week 1 — Hardware, architecture, and requirements

Read chapters 1–3. Practice converting product language into measurable constraints. Build one back-of-the-envelope model each day: CPU cores, in-flight requests, storage growth, bandwidth, and a failure-capacity case.

Deliverables

• A one-page requirements template you can reproduce from memory.
• A 10-minute explanation of monolith, modular monolith, services, event-driven components, and when each fails.
• Two designs in which you explicitly identify the first saturated resource.

Mock: Design a pastebin-like service, then add abuse controls, a tenfold read spike, and zero-downtime schema evolution.

Week 2 — Networking foundations

Read chapters 4–6. Trace a request from application code through DNS, connection establishment, TLS, routing, and the server. Practice explaining latency as a sum of local queueing, round trips, transmission, and remote service time.

Deliverables

• A packet/request-path diagram from browser to a multi-zone service.
• A comparison of TCP, UDP, and application-level reliability for three workloads.
• A DNS failure and migration runbook with TTL and negative caching behavior.

Mock: Design globally routed API ingress for a service that must survive a zone failure and a DNS-provider incident.

Week 3 — HTTP and long-lived communication

Read chapters 7–8. Work through HTTP method semantics, status/error models, caching validators, connection reuse, multiplexing, deadlines, and WebSocket lifecycle.

Deliverables

• An HTTP API that supports safe retry with idempotency keys.
• A connection-capacity estimate for one million mostly idle WebSockets.
• A reconnect/resume protocol with heartbeat, backpressure, and authentication refresh.

Mock: Design multi-device chat presence and messaging, including offline delivery and reconnect storms.

Week 4 — API paradigms and API design

Read chapters 9–10. Implement the same domain as REST, RPC/gRPC, GraphQL, and asynchronous commands. Compare client evolution, caching, schema governance, fan-out, and failure semantics.

Deliverables

• A versioning and compatibility policy.
• A pagination/cursor design that remains stable under concurrent writes.
• An API review checklist covering authorization, quotas, idempotency, and observability.

Mock: Design a public developer API for a project-management product with webhooks and bulk import.

Week 5 — Caching and CDNs

Read chapters 11–12. Practice cache-aside, write-through/behind, refresh, invalidation, stampede protection, negative caching, and edge behavior for private and public content.

Deliverables

• A cache-key specification with tenant/auth/version dimensions.
• A quantitative hit-ratio and origin-capacity model.
• An incident analysis for cache loss, hot key, and bad invalidation.

Mock: Design a globally distributed product catalog and image delivery path for a flash sale.

Week 6 — Proxies, load balancing, and placement

Read chapters 13–14. Compare layer-4/layer-7 routing, health checks, connection pools, algorithms, outlier detection, retries, and consistent/rendezvous hashing.

Deliverables

• A load-balancer policy for short API calls and another for long streams.
• A topology-aware placement plan with node weights and online movement.
• A failure-capacity calculation for zone loss plus repair.

Mock: Design a multi-zone distributed cache that can add 20% capacity without collapsing origin databases.

Week 7 — SQL deep dive

Read chapter 15. Model invariants, transactions, isolation, indexes, query plans, locks, migrations, replicas, and recovery. For every schema, write the two most important queries and the constraint that prevents corruption.

Deliverables

• A payment or inventory transaction traced under two concurrent clients.
• An index design justified by predicates, sort, selectivity, and write cost.
• An expand-and-contract migration for a multi-terabyte table.

Mock: Design ticket booking under a celebrity-scale hotspot.

Week 8 — NoSQL and data modeling

Read chapter 16. Build an access-pattern matrix before selecting a store. Practice partition keys, bounded records, denormalized views, conflicts, repair, and schema evolution.

Deliverables

• Three alternative data models for a timeline or telemetry workload.
• A hot-tenant mitigation and online isolation plan.
• A source-of-truth plus search/read-model rebuild design.

Mock: Design IoT telemetry for millions of devices with recent dashboards and thirteen-month retention.

Week 9 — Replication, sharding, and CAP

Read chapters 17–18 together. Trace acknowledgments, log positions, failover, fencing, read guarantees, partition behavior, and healing. Ban the phrase “pick two” from your answers unless followed by a precise execution.

Deliverables

• A write timeline showing exactly which failures can lose an acknowledged update.
• A safe shard split/move protocol with epochs and rollback.
• An operation-level CAP decision table for money, identity, carts, content, and telemetry.

Mock: Design a multi-region account service and defend its behavior during a region partition.

Week 10 — Object storage and data lifecycle

Read chapter 19. Design metadata plus byte workflows, delegated upload, multipart transfer, immutable versions, integrity, events, lifecycle, privacy deletion, and disaster recovery.

Deliverables

• A direct-upload state machine and orphan reconciliation process.
• A bandwidth/cost model for a viral media object.
• A tested backup/restore plan with explicit RPO and RTO.

Mock: Design user file storage with sharing, versions, malware scanning, and global downloads.

Week 11 — Queues and event-driven systems

Read chapter 20. Draw producer, broker, consumer, and side-effect timelines. Practice outbox/inbox, ordering scope, consumer groups, visibility, retries, DLQ, backpressure, schemas, and replay.

Deliverables

• An effectively-once business workflow using stable operation IDs.
• A backlog growth/drain calculation.
• A schema migration and projection rebuild plan.

Mock: Design order fulfillment across inventory, payment, warehouse, and notification services.

Week 12 — MapReduce, synthesis, and interview simulation

Read chapter 21. Estimate input, map output, shuffle, spill, and output. Practice aggregation algebra, joins, skew, retries, and atomic publication. Then rotate through full designs that combine every layer.

Deliverables

• A MapReduce design for an inverted index or reconciliation job.
• Three full 45-minute mocks, each scored and reattempted.
• A personal “default choices and exceptions” sheet—not memorized architectures.

Mocks: search indexing; global rate limiting; collaborative document storage; analytics pipeline.

Four-week accelerated track

Week	Chapters	Main practice
1	1–6	Requirements, sizing, architecture, network/DNS failure paths
2	7–14	API contracts, real-time connections, caching, load balancing, placement
3	15–19	Data model, transactions, replication, CAP, object lifecycle
4	20–21 plus practice pack	Async workflows, batch, six timed mocks, targeted remediation

Per-topic practice protocol

For each chapter, complete this cycle:

Pass A — 20-minute recall

• Give a two-minute definition and mental model.
• Draw the request/data path.
• Name three alternatives and the deciding workload dimensions.
• State one equation and one failure mode.
• Explain the topic’s interaction with two other chapters.

Pass B — 30-minute deep dive

Pick one senior question. Answer in this order: assumptions, invariant, design, numbers, failure behavior, observability, migration, alternatives. Record the answer and remove filler language.

Pass C — 45-minute design

Use a chapter drill, but add two random injects:

• 20× burst for ten minutes.
• One zone is isolated, not cleanly down.
• Largest tenant is 100× average.
• A dependency returns ambiguous timeouts.
• A privacy deletion request must complete across derived stores.
• You must migrate from the current design without downtime.
• Budget is cut by 40%.
• A new mobile client remains in the wild for two years.

Pass D — repair

Rewrite only the weakest five minutes of the answer and deliver it again. Improvement comes faster from correcting a specific gap than repeating a complete comfortable design.

Interleaved review schedule

Review each topic after roughly 1 day, 1 week, 3 weeks, and 6 weeks. On review, answer questions rather than rereading prose. A topic is retained when you can reconstruct the decision table and failure model, not when the page feels familiar.

Readiness gates

Mid-level gate

You can gather requirements, estimate one scale dimension, draw a coherent design, explain common components, and handle straightforward failure/retry questions.

Senior gate

You consistently identify invariants and ownership, quantify bottlenecks and failure headroom, define degraded behavior, include observability/security/migration, and defend alternatives without being prompted.

Staff-oriented stretch gate

You frame the decision for multiple teams and years: platform boundaries, governance, tenancy, regional strategy, cost allocation, rollout/rollback, organizational ownership, and how evidence will drive evolution.