◐System Design

1. Fundamentals: Reliability, Scalability, Maintainability

Three properties define a "good" production system. Every architectural choice is a trade-off between them.

2. Numbers & Capacity Estimation

You will estimate in every interview. The math is trivial; what matters is *speed and confidence*. Memorize the numbers below cold.

3. Networking: TCP, HTTP, DNS, WebSockets

Distributed systems are conversations across networks. You must know what each layer guarantees and what it doesn't.

4. Data Models: Relational, Document, Graph

The data model is the *single most important architectural decision*. It shapes how you think, what queries are easy, what queries are impossible, and what your scale ceiling looks like.

5. Storage Engines: B-Trees vs LSM Trees

A *storage engine* sits below your query layer and decides how data lives on disk. The choice — B-tree or LSM-tree — drives performance characteristics that ripple through every higher layer.

6. SQL Deep Dive: ACID, Isolation, MVCC

SQL is decades old and still the right default. To design with it well you must understand what transactions actually guarantee — and where they leak.

7. NoSQL Deep Dive: KV, Document, Wide-Column, Graph

"NoSQL" is a marketing umbrella for "not relational." The differences within NoSQL are larger than the differences from SQL. You must reason about each model on its own terms.

8. Encoding & Schema Evolution: JSON, Protobuf, Avro

Programs run on objects in memory. Networks and disks need bytes. Encoding is the bridge — and it's where forward/backward compatibility lives or dies.

9. Caching: Strategies, Eviction, Redis vs Memcached

Caching is the highest-leverage optimization in system design. Memory is ~100,000× faster than disk seek; a cache that absorbs even 80% of reads is the difference between a melted database and a cool one.

10. Replication: Single-Leader, Multi-Leader, Leaderless

Replication = keeping the same data on multiple machines. Why? Availability (survive node loss), read scaling (more replicas = more read capacity), latency (replica close to user), disaster recovery (cross-region copi…

11. Partitioning & Sharding

When one machine can't hold all your data, you split it across many. Partitioning (= sharding) is how. The decision is irreversible-ish — pick wrong and you'll spend years regretting it.

12. Consistency Models, CAP, PACELC

In a distributed system, "consistency" isn't binary. It's a spectrum. Knowing where your system sits — and where you *want* it to sit — is core to every design.

13. Distributed Systems Fundamentals: Faults & Networks

A distributed system is one where "a computer you didn't even know existed can render your computer unusable" (Lamport). Understanding *why* distributed systems are hard is the first step to designing them well.

14. Time, Clocks, and Ordering (Lamport, Vector, TrueTime)

In distributed systems, "what happened first?" is a much harder question than it sounds. Wall clocks lie. The real foundation is causality, captured by logical clocks.

15. Consensus: Paxos, Raft, ZAB

Consensus = a group of nodes agreeing on a single value (or a sequence of values), even when some nodes fail. It's the kernel of every reliable distributed system.

16. Transactions: Local, Distributed, 2PC, Saga, TCC

A transaction is a unit of work that should appear atomic. Local transactions are well-understood. Across services or shards, it gets dramatically harder.

17. Probabilistic Structures: Bloom, Consistent Hashing, Merkle, HLL, Count-Min

A handful of clever data structures show up everywhere in distributed systems. Knowing them is interview table stakes.

18. Load Balancing: L4 vs L7, Algorithms

A load balancer (LB) distributes incoming requests across many servers. It's the first line of defense against an unhealthy node and the first lever for horizontal scale.

19. Message Queues & Event Streaming

Async messaging decouples producers from consumers. Done well, it absorbs spikes, enables independent scaling, and provides reliability through retry. Done poorly, it creates inscrutable distributed bugs.

20. Microservices, Monoliths, Service Mesh

Microservices vs monolith is a religious war that should be a pragmatic choice. Both have their place. The right answer depends on team size, change rate, and operational maturity.

21. API Design: REST, GraphQL, gRPC

APIs are the contracts between systems. Designed well, they outlive their authors. Designed poorly, they outlive them too — painfully.

22. Async Patterns: Pub/Sub, CQRS, Event Sourcing, Saga

The patterns in this chapter all flow from one insight: the act of changing state and the consequences of that change can be decoupled in time. Used wisely, this unlocks scale, integration, and auditability.

23. Rate Limiting & Throttling

Rate limiting protects your service from abuse, accidental hammering, and runaway clients. It's also a productizable feature (per-tier quotas). The algorithms are simple; the operational details are where it gets inte…

24. CDN & Edge Computing

A CDN (Content Delivery Network) is a geographically-distributed cache + acceleration tier between your origin and your users. Done well, it serves 90%+ of bytes from the edge — cutting latency, bandwidth costs, and o…

25. Search Systems: Inverted Index, Elasticsearch

"Find documents matching this query, ranked by relevance" is a deceptively complex problem. The inverted index is the foundational data structure; modern search systems layer ranking, filtering, and faceting on top.

26. Observability: Logs, Metrics, Traces, SLOs

You can't operate what you can't see. Observability = the ability to ask arbitrary questions about your system's behavior in production. The "three pillars" are logs, metrics, traces — but the goal is unified investig…

27. Security: TLS, OAuth, JWT, OWASP

Security in a system design interview = a tax that pays itself back manyfold. Senior engineers think about it from the start; juniors bolt it on.

28. Containers, Kubernetes, Borg

Containers won the deployment war; Kubernetes won the orchestration war. Knowing how they work is now table stakes for any system design discussion.

29. Deployment Patterns: Blue/Green, Canary, Feature Flags

Shipping code is a system design problem. Bad deployment practices are how systems with great architecture still take outages.

30. Batch Processing: MapReduce & Spark

Batch processing handles large bounded data sets — terabytes to petabytes — producing reports, models, and derived data. The patterns shaped modern data engineering and big-data system design.

31. Stream Processing: Kafka Streams, Flink, Exactly-Once

Stream processing operates on unbounded data — events arriving continuously. Done right, you replace nightly batch jobs with seconds-fresh insights and react to events as they happen.

32. Design a URL Shortener (TinyURL / bit.ly)

The classic warm-up. Easy to start, deceptively rich. Gets at: ID generation, KV stores, caching, redirect mechanics, analytics fan-out.

33. Design Twitter / News Feed

The canonical fan-out problem. Tests: timeline construction, push vs pull, hot keys (celebrities), denormalization, caching at scale.

34. Design YouTube / Video Streaming

Tests: object storage, video encoding pipeline, CDN, adaptive bitrate streaming, recommendation, comments, view counting at scale.

35. Design Uber / Ride Hailing

Tests: real-time location, geo-indexing (S2 / H3), matching, dispatch, payments, surge pricing, websockets at scale.

36. Design WhatsApp / Chat at Scale

Tests: long-lived connections, fan-out for messages, message ordering, presence, end-to-end encryption, group chat.

37. Design Dropbox / Google Drive

Tests: file storage at scale, chunking, deduplication, sync engine, conflict resolution, sharing & permissions.

38. Design a Web Crawler

Tests: BFS at planet scale, politeness, deduplication, fault tolerance, distributed coordination.

39. Design Typeahead / Autocomplete

Tests: low-latency suggestions, prefix data structures (trie / FST), ranking, real-time updates, caching.

40. Design Yelp / Geo-Search

Tests: spatial indexing, faceted search, ranking, photos, reviews, abuse handling.

41. Design a Distributed Cache

Tests: consistent hashing, replication, eviction, hot keys, cluster membership, failure handling.

42. Design a Rate Limiter Service

Tests: distributed counter consistency, token bucket math, hot key strategies, latency budget.

43. Design a Notification System

Tests: fan-out, delivery via multiple channels (push/email/SMS), retries, idempotency, rate limiting, user preferences.

44. Design a Payment System

Tests: idempotency, distributed transactions, integration with PSPs, ledger, fraud, regulatory compliance.

45. Design an Ad Click / Counting System

Tests: extreme write throughput, deduplication, fraud detection, real-time aggregation, billing accuracy.

46. The Interview Framework (RESHADED)

System design interviews aren't about getting the "right" answer; they're about demonstrating structured thinking under uncertainty. The interviewer is hiring for whether you can lead a design discussion in a real mee…

47. Cheat Sheet: Common Trade-offs & Patterns

Quick reference. The interviewer rewards reasoning about trade-offs; this distills the recurring ones.

48. Google Papers: GFS, Bigtable, Spanner, MapReduce, Borg

Google publishes its internal systems via papers. The ideas in those papers seeded most modern distributed-systems infrastructure. For a Google interview, knowing them — at least at high level — signals fluency with t…

System Design — End-to-End Curriculum

A comprehensive system design reference built for Google L3/L4 prep. Written from first principles, with trade-offs explicitly called out, and Google-relevant systems (GFS, Bigtable, Spanner, Borg) folded in.

System Design Syllabus — 24 Weeks

Phase 2. Run in parallel with Neetcode (Phase 1) at 30 min/day, then ramp to 1h/day from Aug.