The canonical design lane: Weeks 46–57
System design is a first-class phase of the course - not an afterthought. Twelve weeks take you from the design method, through the distributed patterns, to a family of case studies and OOD/LLD practice.
Every design week runs the same loop. The artifact is a design document, a small implementation or simulation, and an interview-ready explanation - a diagram alone does not count.
requirements, users, SLOs, scale, privacy, and cost
APIs, data model, partitioning, indexes, caches, and queues
contention, failure modes, consistency, replay, recovery, and observability
the AI concern - embeddings, retrieval, inference routing, agent memory, evaluation, safety, or cost attribution
| Week | Core system-design theme | Core case / lab | Evidence |
|---|---|---|---|
| 46 | Delivery framework, requirements, networking, numbers to know | URL shortener / Bitly | Framed design + capacity sheet |
| 47 | API design, data modeling, indexing, contracts | LeetCode problem service | API and schema package |
| 48 | Caching, sharding, consistent hashing, CAP | Rate limiter + distributed cache | Design, key layout, failure table |
| 49 | Replication, read/write scaling, contention | News feed / Instagram | Read path, write path, consistency choice |
| 50 | Large blobs, CDN, metadata, resumable work | Dropbox / Google Docs | Storage design + recovery plan |
| 51 | Queues, workflows, long-running tasks | Job scheduler / Slack job queue | State machine + retry/idempotency plan |
| 52 | Schema evolution, real-time updates, coordination | WhatsApp / notification system | Contract migration + delivery semantics |
| 53 | Search, proximity, crawling, ranking | Yelp / FB post search / web crawler | Index and freshness design |
| 54 | Messaging and social fan-out | FB Live Comments / Tinder / Discord | Fan-out model + hot-key strategy |
| 55 | Scheduling, scarcity, marketplace correctness | Ticketmaster / Uber / local delivery / auction | Reservation invariant + contention test |
| 56 | Streaming, analytics, and data infrastructure | Ad clicks / metrics / Robinhood / Spotify data lake | Stream topology + watermark/replay notes |
| 57 | Integrated architecture and interview boss | ChatGPT / payment system / Figma multiplayer | Staff-level design review + trade-off defense |
The case list is intentionally larger than twelve weeks: each week has one core case plus adjacent cases for comparison, mock interviews, or optional depth. You are not expected to fully implement every analogue.
Use one technology as the concrete substrate for the design pattern. For each tool, state the guarantee it provides and the trade-off it introduces.
| Pattern | Problem | Solution |
|---|---|---|
| Rate limiter | One user or tenant floods the API | Token bucket or sliding window; distributed counter for horizontal scale |
| Caching (LRU, TTL) | Repeat reads on the same keys | Cache-aside with bounded size; TTL plus write-through/invalidation |
| Consistent hashing | Rehashing a hash table when nodes join/leave | Hash ring so a membership change moves only a fraction of keys |
| Read replicas | Read traffic outpaces a single primary | Primary for writes, replicas for reads; handle replication lag |
| Queue + workers | Slow or bursty async work | Durable queue with consumer groups and retries with backoff |
| Idempotency keys | Client retries create duplicate effects | Store request key and result; replay the original outcome |
| Circuit breaker | A downstream dependency is failing | Open the circuit after a threshold, fail fast, then probe |
| Feature flags | Deploying risky code to everyone at once | Dynamic flag rules with gradual rollout and kill switch |
| Replication + leader election | The sealer/scheduler must be a single writer | Lease-based election with fencing so stale leaders cannot commit |
| Append-only ledger | Audit and billing require exact history | Immutable event log; materialize dashboards separately |
Introduction, how to prepare, delivery framework, core concepts, key technologies, common patterns, networking essentials, API design, data modeling, and numbers to know.
Caching, sharding, consistent hashing, CAP, database indexing, scaling reads, scaling writes, real-time updates, contention, multi-step processes, long-running tasks, large blobs, replication, schema evolution, and observability.
| Family | Cases |
|---|---|
| Storage and collaboration | Dropbox, Google Docs, Discord message storage, Figma multiplayer |
| Messaging and notifications | WhatsApp, FB Live Comments, notification system, Slack job queue |
| Search and retrieval | Yelp, FB Post Search, proximity search, web crawler, ChatGPT |
| Scheduling and logistics | Job Scheduler, Uber, local delivery, Ticketmaster, online chess |
| Streaming and analytics | Ad Click Aggregator, Metrics Monitoring, Robinhood, Spotify Data Lake |
| Marketplace and money | Online Auction, Payment System, Shopify Inventory Reservations |
| Social products | FB News Feed, Instagram, Tinder, Strava, News Aggregator |
| Platform primitives | Bitly, Distributed Cache, Rate Limiter, YouTube, YouTube Top K, LeetCode, Price Tracking Service |
Ten of the families are worked in depth across the twelve weeks.
Hashing, ID generation, cache, 301 vs 302
Blob storage, chunking, sync conflicts, metadata DB
Hot-row contention, seat holds, payment idempotency
Fan-out on write vs read, ranking feed cache
Presence, message delivery, mobile constraints
Sandboxing, queue, result correctness
Geo-spatial indexing, dispatch, ETA aggregation
Frontier, politeness, deduplication, fault tolerance
Streaming aggregation, windowing, at-least-once semantics
Idempotency, ledger correctness, settlement
Object-oriented design runs as the Thursday implementation/interview variant - practice correctness, coordination, scarcity, OOP concepts, design principles, and patterns.
Each LLD artifact must state its invariants, ownership boundaries, concurrency policy, and extension points. The distributed design then explains how the single-process model changes when state is replicated or partitioned.
Every design gets one AI extension so the track connects directly to the rest of Tensor-to-Tenant.
| Base design | AI extension |
|---|---|
| Semantic search, agent memory, PII-safe message retrieval | |
| Search / Yelp | Hybrid BM25+dense retrieval, reranking, slice evaluation |
| Job scheduler | Tool-call DAGs, retries, cancellation, quota-aware admission |
| ChatGPT | Conversation storage, prompt registry, routing, KV cache, evaluation |
| Streaming metrics | Token/cost attribution, watermarking, late-event correction |
| Payment / reservations | Idempotency, exactly-once effects, auditability, contention |
| Figma multiplayer | Collaborative agent state, conflict resolution, presence |
| Distributed cache | Semantic and embedding cache with tenant isolation |
- Requirements & constraints
- Clarify scale, SLOs, budget, and non-goals before proposing a stack
- API design
- Resource-oriented contracts, pagination, idempotency, error shapes
- Data modeling
- Relational vs document vs columnar; denormalization for reads
- Distributed patterns
- Rate limiting, caching, queues, consistent hashing, replication, leader election
- Failure analysis
- Identify single points of failure and design for partial outage
- Trade-off defense
- Justify every choice: consistency, cost, complexity, operations
By Week 57 you must be able to choose a case from any family and, under interview time pressure, produce:
- requirements and SLOs
- API and data model
- partition, index, cache, queue, and replication choices
- capacity estimates and a bottleneck plan
- consistency, contention, idempotency, and failure semantics
- observability, privacy, tenant isolation, and cost controls
- one AI extension and a clear trade-off defense