System Design

Study requirement gathering (functional and non-functional), back-of-envelope capacity estimation, horizontal vs. vertical scaling, caching layers, load balancing strategies, database replication and sharding, and message queues for decoupling services.

Estimating scale (QPS, storage, bandwidth) before designing, stateless vs. stateful services, cache placement and invalidation, load balancer algorithms (round robin, least connections), read replicas vs. sharding for database scale, and the CAP theorem's consistency-availability tradeoff under partition.

Every real system design decision trades one property for another — more caching means staler data, more replicas means harder consistency, more queueing means more latency. Naming these tradeoffs explicitly, instead of pretending a design has none, is what production systems actually require.

There's no single "correct" architecture — what matters is estimating scale, justifying each component you add, and naming the tradeoff it introduces, especially around consistency, latency, and failure handling.