System Design Mastery: 11-Week Intensive Program.

Program Overview#

This program transforms intermediate backend engineers into system design experts through structured, progressive learning. Each week builds on the previous, creating a comprehensive understanding of distributed systems.

Format: 1 hour daily, 5 days/week (Week 8 has a sixth day), 11 weeks after Week 0 Total Investment: 56 hours of focused study, plus Week 0 Prerequisites: Basic understanding of databases, APIs, and web services

How to Use This Plan#

Each day includes:

• Core concepts with intuitive explanations
• Production-ready code implementations
• Real-world case studies from top tech companies
• Interview-focused practice problems
• Trade-off discussions and decision frameworks

Daily Structure:

• Concept Foundation: Understand the "why" before the "how"
• Implementation Deep-Dive: See how concepts translate to code
• Real-World Application: Learn from production systems
• Interview Preparation: Practice explaining and defending designs

Document everything. Build your personal system design reference as you progress.

Goal: Build the prerequisite knowledge needed for system design mastery

Before diving into system design patterns, you need a solid foundation in core concepts. Week 0 ensures everyone starts with the same mental models and vocabulary.

Week 0 Structure#

Part 1: System Design Methodology#

Core framework for approaching any design problem

What you'll learn:

• High-Level Design (HLD) vs Low-Level Design (LLD)
• The RADCE Framework: Requirements → API → Data → Core Components → Extended Features
• How to structure your thinking in interviews
• Common mistakes and how to avoid them

Key takeaways:

• Never start designing without clarifying requirements
• Always define APIs before implementation
• Data model decisions constrain everything else

Part 2: Infrastructure Building Blocks#

The components you'll combine into systems

What you'll learn:

• Load Balancers (L4 vs L7, algorithms, health checks)
• Reverse Proxies and API Gateways
• Databases (SQL vs NoSQL, when to use each)
• Caching layers (Redis, Memcached, CDN)
• Message Queues (RabbitMQ, Kafka, SQS)
• Storage systems (Block, Object, File)
• DNS and how it affects system design

Key takeaways:

• Each component has specific trade-offs
• Choosing the right building block is half the design
• Understanding internals helps you make better decisions

Part 3: Back-of-Envelope Estimation#

The math that guides design decisions

What you'll learn:

• Latency numbers every engineer should know
• Traffic estimation (DAU → QPS → Storage)
• The "Rule of 72" for capacity planning
• Common estimation patterns and shortcuts
• How to sanity-check your calculations

Key takeaways:

• Estimation drives architecture decisions
• Know your powers of 2 and time conversions
• Practice until estimation becomes intuitive

Part 4: Networking Fundamentals#

How data moves through your systems

What you'll learn:

• OSI/TCP-IP model and practical implications
• TCP vs UDP (when to use each)
• HTTP/1.1 → HTTP/2 → HTTP/3 evolution
• WebSockets and Server-Sent Events
• gRPC and protocol buffers
• TLS/SSL and security fundamentals
• DNS deep-dive

Key takeaways:

• Network is the foundation of distributed systems
• Protocol choice affects latency, reliability, and complexity
• Security must be built in, not bolted on

Part 5: Operating System Concepts#

How your code actually runs

What you'll learn:

• Processes vs Threads (and when to use each)
• Memory management and virtual memory
• I/O models (blocking, non-blocking, async, epoll)
• File systems and persistence
• Context switching and performance implications
• Linux tuning for high-performance systems

Key takeaways:

• OS concepts explain why systems behave as they do
• Understanding I/O models is crucial for scalability
• System limits are tunable (and often need tuning)

Part 6: Terminology and Theory#

The language of distributed systems

What you'll learn:

• CAP Theorem (and why it's misunderstood)
• PACELC Theorem (extending CAP)
• ACID vs BASE (and when to choose each)
• Consistency models (linearizable → eventual)
• Replication strategies (leader, multi-leader, leaderless)
• Sharding and partitioning approaches
• Consensus and coordination

Key takeaways:

• Trade-offs are unavoidable in distributed systems
• Terminology precision matters in interviews
• Theory informs practice

Part 7: API Design#

Designing the contract between services

What you'll learn:

• Resources, HTTP semantics and status codes
• Pagination: offset vs cursor (keyset) pagination
• Versioning and backward-compatible changes
• Error contracts and idempotency keys
• Rate limits and long-running operations
• REST vs gRPC vs GraphQL, and auth basics

Key takeaways:

• The API is designed in the first ten minutes and shapes everything after it
• Every write that can be retried needs an idempotency key
• Cursors, not offsets, for lists that grow

Part 8: Databases in Depth#

What one database server does inside

What you'll learn:

• Storage engines: B-trees vs LSM trees, the WAL
• Indexes: what each one buys on reads and costs on writes
• Isolation levels, the anomalies each prevents, and MVCC
• Pessimistic and optimistic locking
• A decision framework for choosing a database
• Generating IDs (random UUIDs vs time-ordered IDs, Snowflake)

Key takeaways:

• Know why you pick a database, not just which one
• Every index speeds some reads and slows every write
• Isolation levels decide which race conditions you still have to handle

Week 0 Summary#

Week 0 provides comprehensive coverage of all prerequisite knowledge.

Goal: Build mental models for distributed thinking

Week 1: Data at Scale — Storage Trade-offs#

Weekly Goal#

Stop thinking "which database" → Start thinking "which storage pattern for which access pattern"

Key Concepts#

• Write-ahead logs and why every durable system uses them
• LSM trees vs B-trees: When writes matter vs when reads matter
• Partitioning strategies: Hash vs Range vs Directory-based
• Replication: Sync vs Async and what you're actually trading
• CAP theorem in practice (not theory): What does "partition" actually mean in your cloud?

Systems to Design#

1. URL Shortener at 100M daily creates — Focus on: ID generation, hot-key problem, read vs write paths
2. Rate Limiter (distributed) — Focus on: Consistency vs availability, sliding window algorithms
3. User Session Store — Focus on: TTL strategies, consistency requirements, failover behavior

Daily Breakdown#

Day 1: Partitioning Deep-Dive

• Hash vs range partitioning trade-offs
• Consistent hashing and virtual nodes
• Designing for data locality

Day 2: Replication Trade-offs

• Sync vs async replication implications
• Read-after-write consistency
• Handling replication lag

Day 3: Rate Limiting at Scale

• Algorithm comparison (sliding window, token bucket, leaky bucket)
• Distributed rate limiting challenges
• Failure mode decisions

Day 4: Hot Keys and Skew

• Detection and mitigation strategies
• Scatter-gather patterns
• Real-world examples (viral content, celebrity problem)

Day 5: Session Store Design

• Sticky sessions vs distributed sessions
• Failover and consistency
• Technology selection (Redis Cluster, DynamoDB, custom)

Expected Outcomes#

Week 2: The Network is Not Reliable — Failure-First Design#

Weekly Goal#

Design systems assuming everything fails. Internalize: latency, partial failures, timeouts.

Key Concepts#

• Failure modes: Crash vs Omission vs Byzantine
• Timeouts: Why they're hard. Cascading failures from bad timeout choices
• Retry strategies: Exponential backoff, jitter, retry budgets
• Circuit breakers: States, transitions, when they hurt more than help
• Idempotency: Keys, deduplication windows, exactly-once is a lie

Systems to Design#

1. Payment Processing Pipeline — Focus on: Exactly-once semantics, idempotency, reconciliation
2. Webhook Delivery System — Focus on: Retry strategies, dead letter queues, delivery guarantees
3. Distributed Cron / Job Scheduler — Focus on: Leader election, missed job handling

Daily Breakdown#

Day 1: Timeout Management

• Timeout budgets and propagation
• Adaptive timeouts
• Cascading failure prevention

Day 2: Idempotency in Practice

• Idempotency key strategies
• Client-generated vs server-generated keys
• Deduplication windows and TTLs

Day 3: Circuit Breakers

• States and transitions
• Configuration tuning
• When circuit breakers cause more harm

Day 4: Webhook Delivery

• Delivery guarantees
• Retry strategies with exponential backoff
• Dead letter queue design

Day 5: Distributed Cron

• Leader election patterns
• Fencing tokens
• Exactly-once execution strategies

Expected Outcomes#

Goal: Master the components you'll compose into larger systems

Week 3: Messaging and Async Processing#

Weekly Goal#

Know when to use queues, when to use streams, when to use neither. Design for exactly the guarantees you need.

Key Concepts#

• Queue vs Log: RabbitMQ mental model vs Kafka mental model
• Consumer groups, partitions, and ordering guarantees
• Backpressure: Detection and handling strategies
• Dead letter queues: Not a trash can, a signal
• Transactional outbox pattern: Why "save to DB then publish" fails

Systems to Design#

1. Order Processing Pipeline — Focus on: Ordering guarantees, failure handling, idempotent consumers
2. Event-Driven Notifications — Focus on: Fan-out, priority queues, rate limiting to external providers
3. Audit Log System — Focus on: Immutability, exactly-once semantics, long-term storage

Daily Breakdown#

Day 1: Queue vs Stream

• When RabbitMQ? When Kafka? Redis Streams? SQS?
• Ordering guarantees and consumer groups
• Technology selection framework

Day 2: Transactional Outbox

• Why "save then publish" fails
• Outbox pattern implementation
• Polling vs CDC approaches

Day 3: Backpressure and Flow Control

• Symptoms and detection
• Response strategies
• Designing for graceful degradation

Day 4: Dead Letters and Poison Pills

• DLQ strategies
• Debugging and replay mechanisms
• Operational tooling

Day 5: Audit Log System

• Immutability requirements
• Compliance considerations
• Storage and query patterns

Expected Outcomes#

Week 4: Caching — Beyond "Just Add Redis"#

Weekly Goal#

Cache strategically, not reflexively. Understand invalidation, consistency, and thundering herds.

Key Concepts#

• Cache-aside vs Read-through vs Write-through vs Write-behind
• Invalidation strategies: TTL, event-driven, versioned keys
• Thundering herd: Locking, probabilistic early expiration, request coalescing
• Multi-tier caching: Edge → App → Database caches
• Cache warming strategies

Systems to Design#

1. Product Catalog Cache — Focus on: Consistency with inventory, invalidation strategies
2. User Feed Cache — Focus on: Personalization, cache-per-user vs shared cache
3. API Response Cache — Focus on: Varying on headers, authentication, cache busting

Daily Breakdown#

Day 1: Caching Patterns

• Cache-aside vs read-through vs write-through
• When write-behind is safe
• Pattern selection framework

Day 2: Invalidation Strategies

• TTL-based vs event-driven
• Why invalidation is the hardest problem
• Consistency trade-offs

Day 3: Thundering Herd

• Problem identification
• Locking approaches
• Probabilistic early expiration

Day 4: Feed Caching

• Cache-per-user vs computed-on-request
• Push-on-write vs pull-on-read
• Celebrity/hot key problem

Day 5: Multi-Tier Caching

• CDN → API Gateway → App → DB layers
• What belongs where
• Invalidation at each tier

Expected Outcomes#

Week 5: Consistency and Coordination#

Weekly Goal#

Understand the cost of consistency. Know when you need it and when you're paying for something you don't use.

Key Concepts#

• Consistency models: Strong, eventual, causal, read-your-writes
• Distributed transactions: 2PC, Saga, and why they're both painful
• Consensus: Raft/Paxos conceptually. When you need it vs when you think you do
• Conflict resolution: Last-write-wins, vector clocks, CRDTs
• Fencing and leader election in practice

Systems to Design#

1. Inventory Management — Focus on: Preventing oversell, consistency vs performance
2. Money Transfer Between Accounts — Focus on: ACID across services, saga compensation
3. Collaborative Document Editing — Focus on: Conflict resolution, operational transforms vs CRDTs

Daily Breakdown#

Day 1: Consistency Models in Practice

• Strong vs eventual implications
• Consistency guarantees spectrum
• Choosing the right level

Day 2: Distributed Transactions — Saga Pattern

• Why 2PC is avoided in microservices
• Choreography vs orchestration
• Compensation design

Day 3: Saga Orchestration in Detail

• State machines
• Workflow engines (Temporal/Cadence)
• Failure handling

Day 4: Conflict Resolution

• Last-write-wins problems
• Vector clocks
• CRDTs for specific use cases

Day 5: Leader Election and Coordination

• Why leader election is hard
• Fencing tokens
• Split-brain prevention

Expected Outcomes#

Goal: Design end-to-end systems with all components integrated

Week 6: Designing a Notification Platform#

Weekly Goal#

Design a complete notification system: multi-channel, reliable, scalable, observable.

Why This System#

It touches everything: queues, rate limiting, external integrations, user preferences, delivery guarantees, observability.

System Requirements#

• Channels: Email, SMS, Push, In-app, Webhook
• Scale: 10M notifications/day, bursty (marketing campaigns)
• Reliability: At-least-once delivery, retry with backoff
• Features: User preferences, rate limiting, scheduling, templates
• Operational: Delivery tracking, debugging tools, cost monitoring

Daily Breakdown#

Day 1: Designing a Real-Time Notification Platform

• Requirements, estimates and the high-level architecture
• Data model: notifications, deliveries, inbox, preferences, device tokens
• Channel trade-offs and consent rules

Day 2: The Delivery Pipeline: Guarantees, Priorities and Preferences

• Idempotent send API and the transactional outbox
• Preferences, quiet hours, batching and priority lanes
• Retries, dead letters and scheduling

Day 3: Real-Time Channels: WebSockets and SSE at Scale

• Polling vs SSE vs WebSockets
• The gateway tier and the connection registry
• Heartbeats, reconnect storms and graceful drains

Day 4: Presence and Chat Fan-Out at Scale

• Presence and typing indicators
• Message fan-out, ordering and receipts
• Offline and multi-device delivery

Day 5: Operations, Scale and Edge Cases

• What to measure, SLOs and paging
• Bursts, provider failover and cost
• Regions and edge cases

Expected Outcomes#

Week 7: Designing a Search System#

Weekly Goal#

Design search infrastructure for a product catalog or content platform.

Why This System#

It teaches: indexing pipelines, eventual consistency, relevance tuning, performance optimization.

System Requirements#

• Content: 10M products/documents
• Queries: 1000 QPS, p99 < 200ms
• Features: Full-text search, filters, facets, autocomplete, typo tolerance
• Freshness: New products searchable within 5 minutes
• Operational: Index updates without downtime

Daily Breakdown#

Day 1: Search Fundamentals and Architecture

• Inverted index concepts
• Technology selection (Elasticsearch vs Algolia vs custom)
• High-level architecture

Day 2: Indexing Pipeline

• Change data capture
• Batch vs streaming indexing
• Schema evolution

Day 3: Query Path Optimization

• Query parsing and analysis
• Caching strategies
• Autocomplete design

Day 4: Typeahead at Scale

• Prefix data structures and a precomputed top-k suggestion index
• Serving every keystroke in milliseconds
• "Did you mean" and faceted filtering

Day 5: Location Search and Search at Scale

• Geohash, quadtrees, S2 and H3 cells for "near me" queries
• Radius and k-nearest queries; things that move
• Topology, shard sizing and reindexing

Expected Outcomes#

Week 8: Designing an Analytics Pipeline#

Weekly Goal#

Design a data pipeline from event ingestion to queryable analytics.

Why This System#

It teaches: streaming vs batch, data modeling for analytics, late-arriving data, exactly-once in pipelines.

System Requirements#

• Ingestion: 100K events/second peak
• Storage: 1 year retention, queryable
• Query: Ad-hoc analytics, dashboards, real-time (< 5 min latency)
• Data quality: Deduplication, late-arriving data handling
• Cost: Storage and compute cost optimization

Daily Breakdown#

Day 1: Event Ingestion

• Schema design and versioning
• Validation and rejection strategies
• Backwards compatibility

Day 2: Streaming vs Batch

• Lambda vs Kappa architecture
• When streaming, when batch
• Technology selection

Day 3: Storage and Data Modeling

• Columnar storage
• Partitioning strategies
• Time-series patterns

Day 4: Late-Arriving Data and Correctness

• Event time vs processing time
• Watermarks and allowed lateness
• Correction strategies

Day 5: Query Layer and Cost

• OLAP databases
• Materialized views
• Cost optimization

Day 6: Counting at Scale

• Bloom filters for membership
• HyperLogLog for distinct counts
• Count-Min Sketch and top-k for frequencies

Expected Outcomes#

Goal: Handle the messy realities of production systems

Week 9: Multi-Tenancy, Security, and Compliance#

Weekly Goal#

Design systems that serve multiple customers with isolation, security, and compliance requirements.

Key Concepts#

• Tenant isolation: Shared vs siloed. Database, compute, network isolation
• Noisy neighbor: Detection and prevention
• Data residency: GDPR, data localization requirements
• Encryption: At rest, in transit, application-level
• Audit and compliance: Logging, access control, data retention

Systems to Design#

1. Multi-tenant SaaS Backend — Focus on: Tenant isolation strategies
2. GDPR-Compliant Data Architecture — Focus on: Right to deletion, data export, consent management

Daily Breakdown#

Day 1: Tenant Isolation Strategies

• Shared DB vs schema-per-tenant vs DB-per-tenant
• Cost vs isolation trade-offs
• Row-level security

Day 2: Noisy Neighbor Prevention

• Resource quotas
• Rate limiting per tenant
• Fair scheduling

Day 3: Data Residency and GDPR

• Data localization requirements
• Cross-border transfers
• Architecture implications

Day 4: Right to Deletion

• GDPR Article 17 requirements
• Deletion across systems
• Audit trails

Day 5: Security Architecture

• Defense in depth
• Zero trust principles
• PII protection

Expected Outcomes#

Week 10: Production Readiness and Operational Excellence#

Weekly Goal#

Design systems that are operable, debuggable, and evolvable.

Key Concepts#

• SLIs, SLOs, SLAs: Defining and measuring reliability
• Observability: Metrics, logs, traces — and how they connect
• Deployment strategies: Blue-green, canary, feature flags
• Capacity planning: Load testing, bottleneck identification
• Incident management: On-call, runbooks, postmortems

Activities#

This week focuses on operationalizing previous designs.

Daily Breakdown#

Day 1: Defining SLOs

• SLI vs SLO vs SLA
• Error budgets
• Measurement precision

Day 2: Observability Design

• Three pillars (metrics, logs, traces)
• Correlation IDs
• Distributed tracing

Day 3: Deployment and Rollback

• Canary deployments
• Feature flags
• Database migration strategies

Day 4: Capacity Planning

• Load testing methodology
• Bottleneck identification
• Scaling decisions

Day 5: Incident Management

• On-call best practices
• Runbook structure
• Blameless postmortems

Expected Outcomes#

Goal: Build reliable products on top of large language models

Week 11: Designing AI Systems#

Weekly Goal#

Design production AI features: serving, retrieval, evaluation, guardrails, cost and operations.

Why This System#

AI features in production are distributed systems with new failure modes. Timeouts, idempotency, queues, caches, rate limits and SLOs all still apply; what's new is the dependency at the centre.

Daily Breakdown#

Day 1: LLM Serving: Tokens, Latency and Cost

• Tokens, time to first token and time per token
• Batching, the KV cache and streaming responses
• Rate limits, admission control and cost per token

Day 2: Embeddings and Vector Search

• Embeddings and nearest-neighbour search
• HNSW, IVF and product quantisation; recall vs latency
• Metadata filtering, hybrid search, sizing and sharding

Day 3: RAG Systems

• Ingestion, chunking and keeping the index fresh
• Retrieval, reranking and context assembly within the token budget
• Citations, grounding and access control at retrieval time

Day 4: Evaluation and Guardrails

• Golden sets, the eval harness and LLM-as-judge
• RAG metrics, online metrics and A/B tests
• Prompt injection, PII, hallucination controls and fallbacks

Day 5: Cost, Caching and Operations

• Provider prompt caching and application-level caches
• Routing, cascades, batch APIs and budget governors
• Observability, cost attribution and incident runbooks

Expected Outcomes#

Program Summary#

Weekly Overview#

Recommended Resources#

Books (skim relevant chapters, don't read cover-to-cover):

• Read

  "Designing Data-Intensive Applications" — Chapters on replication, partitioning, consistency

• Read

  "System Design Interview Vol 1 & 2" — Use as problem prompts, not solutions

• Blog

  "Site Reliability Engineering" — Operations and SLO chapters

Engineering Blogs (read when relevant to weekly topic):

• Blog

  Uber, Stripe, Netflix, LinkedIn engineering blogs

• Blog

  Specific posts on systems you're designing that week

Tools to Know:

• Read

  Draw.io or Excalidraw for diagramming

• Docs

  Keep a shared doc for all your designs

Success Metrics#

After completing this program, you should be able to:

1. Design any backend system from scratch in 45 minutes with clear trade-offs
2. Critique designs by injecting failures and scale challenges
3. Speak precisely about consistency, availability, and partition tolerance
4. Produce documentation that a team could implement from
5. Operate systems — know what metrics to watch, how to debug, when to page

Final Note#

This program is intense. You'll feel uncomfortable. That's the point.

The goal isn't to memorize solutions — it's to build intuition for trade-offs.

After 11 weeks, when someone asks "how would you design X?", your first instinct should be: "What are the constraints? What can we sacrifice?"

That's senior engineering thinking.

Good luck. Build something great.