System Design

Traffic management is about controlling how requests reach your servers before your business logic ever runs: which server handles a request, how close to the user it's served from, and how much of it you let through at all. The core mental model is a funnel with several narrowing stages — DNS/anycast picks a region, a CDN absorbs anything cacheable at the edge, a load balancer spreads what's left across a fleet, an API gateway adds cross-cutting policy, and rate limiting caps abuse before it reaches anything expensive. Candidates who treat this as 'just put a load balancer in front' miss that these components form a pipeline, each shedding load so the next layer sees a smaller, safer slice of traffic. It matters because almost every system design interview starts with 'how do requests get to my servers,' and a crisp answer here signals you think about a system as layers of defense, not a single box that does everything.

Performance components exist to make the common case fast by avoiding unnecessary work: recomputation, redundant I/O, or scanning data that isn't relevant. The dominant technique is caching in its many forms (in-process, distributed, edge, database buffer pool), complemented by probabilistic structures like Bloom filters that answer 'is this definitely not present' in constant time and space. The mental model an interview candidate should hold is that performance work is really a trade of memory and staleness for latency — you're never getting something for free, you're choosing where in the stack to pay the cost. This category matters because nearly every system design question eventually gets to 'the database can't take this load' or 'this needs to respond in under 100ms,' and the answer is almost always a well-placed cache or a way to skip work entirely, not a bigger database.

Storage is about choosing the right system to durably hold data and expose the right access pattern — not just 'where do bytes live' but 'what queries need to be fast, what consistency do we need, and how does this scale.' The core skill is matching a data shape and access pattern (key-value lookups, full-text search, large binary blobs, relational joins) to the storage system built for it, rather than defaulting to a single relational database for everything. A candidate with a strong mental model treats storage choice as a first-class design decision made early, because it constrains almost everything downstream: how you shard, how you keep replicas consistent, and how expensive certain queries become. This matters in interviews because 'what database would you use and why' is one of the most common and most differentiating questions asked.

Distribution and partitioning is about splitting data or work across many machines so no single node has to hold everything or do everything, while keeping the system able to grow or shrink without massive disruption. The central mental model is that naive partitioning schemes (like `hash(key) % N`) break catastrophically when the number of nodes changes, whereas techniques like consistent hashing are specifically designed to make topology changes cheap by remapping only a small fraction of keys. This category also covers generating unique identifiers across independent nodes without a central bottleneck — a subtler distribution problem that trips up candidates who assume a single auto-increment counter is always available. It matters because almost every 'how does this scale to billions of X' question ultimately reduces to 'how do we split X across N machines and route to the right one.'

This category covers decoupling producers and consumers in time: instead of a caller blocking on an immediate response, work is handed off (via a queue, pub/sub topic, or long-lived connection) and processed independently. The mental model is that synchronous request/response couples the availability and latency of two services together, while async communication trades immediate consistency for resilience — a slow or temporarily down consumer doesn't take down the producer, and consumers can be scaled or retried independently. This matters in interviews whenever the question involves fan-out to many consumers, work that can be deferred (notifications, emails, video encoding), or bidirectional low-latency updates (chat, live feeds), because reaching for synchronous HTTP everywhere in those cases is a common and easily-spotted design smell.

Reliability covers everything that keeps a distributed system correct and available when individual parts inevitably fail: consensus for agreeing on a single truth despite failures, distributed locks for mutual exclusion, circuit breakers and health checks for containing failure blast radius, and the theoretical grounding (CAP, vector clocks/CRDTs, distributed transactions) for reasoning about what guarantees are even possible. The mental model every candidate needs is that failure is not an edge case in distributed systems — it's the normal operating condition, and every component in this category exists to answer 'what happens when this part breaks, and how does the rest of the system keep working (or fail gracefully) despite it.' This is often the highest-signal category in an interview because it's where junior and senior answers diverge most sharply: junior candidates design the happy path, senior candidates design for partial failure from the start.

Networking and delivery is about the plumbing that gets a request from a client's DNS lookup all the way to the correct internal service, and increasingly, how services talk to each other inside a cluster. DNS resolves a name to an address (often the first and most overlooked hop in a design), reverse proxies terminate and forward connections to internal services, and a service mesh adds a uniform, observable communication layer between microservices (mTLS, retries, traffic shaping) without changing application code. The mental model here is layered indirection: each hop exists to decouple 'who I'm talking to' from 'where that thing actually lives,' which is what makes it possible to move, scale, or replace backend services without breaking clients. It matters in interviews because candidates who skip straight from 'client' to 'server' in their diagram miss the infrastructure that makes service discovery, TLS, and internal traffic control possible at scale.

Data processing is about transforming and analyzing data at scale, either in scheduled bulk chunks (batch) or continuously as it arrives (stream). The core mental model is a spectrum of latency vs. completeness: batch jobs can look at a complete, stable dataset and produce fully correct aggregates but only periodically, while stream processing gives near-real-time results by processing events as they flow through, at the cost of having to handle out-of-order data, windowing, and approximate or eventually-corrected results. Recognizing which end of that spectrum a requirement sits on — 'nightly report' versus 'live dashboard' — is what separates a workable design from an over- or under-engineered one. This matters in interviews whenever the question involves analytics, recommendations, fraud detection, or any derived data that isn't simply CRUD on a primary store.

Observability and ops covers how you know what your system is actually doing in production and how you safely change its behavior without redeploying: metrics, logs, and traces to answer 'what happened and why,' and feature flags to control rollout and blast radius of new behavior independently of deployment. The mental model is that a system you can't observe is a system you can't operate — you cannot debug, capacity-plan, or safely roll back what you can't measure, and you cannot safely ship risky changes without a way to turn them off instantly. This category is often under-discussed by candidates by default, but bringing it up unprompted (e.g. 'I'd add tracing here to debug cross-service latency, and gate this new ranking algorithm behind a flag') is a strong signal of production experience, since it shows the design accounts for its own lifecycle after launch, not just its initial correctness.

Security in a system design interview is primarily about authentication and authorization — proving who a caller is and deciding what they're allowed to do — plus the broader posture of not trusting any input or hop by default. The mental model is defense in depth: identity is established once (login, token issuance) and then verified cheaply at every subsequent hop (API gateway, service mesh, individual services) rather than re-checked expensively or, worse, trusted implicitly after the first check. This matters in interviews because security is easy to bolt on as an afterthought ('we'll add auth later'), and interviewers specifically probe whether a candidate treats identity, token expiry/revocation, and least-privilege access as first-class design constraints rather than a checkbox mentioned at the end.