Networking Essentials
Networking Essentials: an engineer-focused guide to the requirements, trade-offs, architecture, and interview decisions that matter.
This article has an interactive companion
Don't just read it — step through it interactively, one state change at a time.
A networking essentials answer is not a diagram contest. It is a sequence of explicit promises: what callers can do, how much traffic the system can absorb, and which failure modes are acceptable. The useful design is the smallest one that meets those promises and has a credible path to the next order of magnitude.
The details below are deliberately concrete. In an interview, numbers expose hidden assumptions; in production, they decide whether a queue, cache, index, or partition key is the right tool.
Requirements before components
Start by separating the user-visible operation from the guarantees behind it. The request path, correctness boundary, and observable failure response should be named before choosing infrastructure.
A clean functional requirement says what a caller can ask for and what response it receives. A non-functional requirement names a bound: latency, durability, availability, freshness, ordering, or cost. Those statements prevent a common mistake: selecting a familiar datastore before deciding what must be true.
Capacity and the shape of the workload
Capacity estimates do not need false precision; they need assumptions that can be challenged. Convert daily volume to average requests per second, then multiply for peak. Estimate object size separately from metadata, and distinguish read-heavy from write-heavy paths. A read path at 100,000 requests/s with a 95% cache hit rate sends 5,000 requests/s to storage, while a 0% hit rate does not.
For each API, estimate peak QPS, payload bytes, retention, and a p99 latency target. Those four numbers determine whether one database is sufficient or whether the design needs partitioning, asynchronous work, and a cache.
A high-level architecture that can evolve
Place stateless API instances behind a load balancer. Keep the synchronous path short: authenticate, validate, read or write the authoritative state, and return. Move fan-out, enrichment, indexing, notifications, analytics, and retries to durable queues when the caller does not need their result immediately.
The data model should make the dominant lookup cheap. A key-value access pattern wants a stable partition key; a time-ordered feed wants a cursor plus a sort key; geospatial or text lookup needs an index built for that query. Replicas improve read capacity, but they also create a freshness question. State explicitly whether a read must observe its own write or may be eventually consistent.
| Decision | Default | Cost paid |
|---|---|---|
| Synchronous work | Only work needed for the response | Lower tail latency |
| Cache | Read-hot, recomputable data | Fewer storage reads |
| Queue | Retryable asynchronous work | Absorbs bursts |
| Partitioning | Stable high-cardinality key | Horizontal scale |
Deep dives and failure boundaries
Identify the hottest key, the largest object, and the dependency that can fail. Add an idempotency key to retryable writes, a deadline to every remote call, and metrics for saturation, error rate, and queue lag. A design is incomplete until it says what happens when a dependency is slow or unavailable.
A good failure policy is product policy, not merely an infrastructure setting. Fail-open may preserve availability while exposing a downstream service; fail-closed may protect correctness while rejecting useful work. Pick the behavior per operation, instrument it, and make the degraded response visible to clients.
How this shows up in interviews
Interviewers usually probe the boundary between a plausible diagram and an operable system. Expect follow-ups about the partition key, cache invalidation, duplicate delivery, hot partitions, multi-region behavior, and how the first version changes at ten times the load. Walk through one request end-to-end, name the source of truth, then explain the trade-off you would reverse if the workload changed.
Explore it interactively on YeetCode. Related practice: Load Balancing, API Gateway, Scaling, CDN.
Further learning
- Revisit the failure modes and capacity assumptions in the interactive roadmap before optimizing individual components.
FAQ
What should I draw first in a system-design interview?
Start with the client, API boundary, authoritative data store, and the one or two asynchronous paths. Add named components only when a requirement requires them.
How detailed should capacity math be?
Show the conversion from a stated workload to peak QPS, storage, and bandwidth. Round numbers are fine when the assumption and the resulting design choice are clear.
When should work go through a queue?
Use a durable queue when callers do not require the result before returning and the work benefits from buffering, retries, or independent scaling. Make consumers idempotent because delivery can repeat.
Make it stick: run this one yourself
Don't just read it — step through it interactively, one state change at a time.