System design is the process of defining a system's components, interfaces, data flows, and operational properties to meet functional and non-functional requirements. In an interview, clarify requirements first, estimate scale, propose a high-level architecture, explore critical components, and explain trade-offs. There is rarely one universally correct design; the quality of reasoning matters.

Use a repeatable sequence: (1) clarify functional requirements and out-of-scope items, (2) identify non-functional requirements and SLOs, (3) estimate traffic, storage, and bandwidth, (4) define APIs and data models, (5) draw the high-level architecture, (6) deep-dive into bottlenecks and consistency, and (7) cover reliability, security, observability, and trade-offs. Adjust depth to the time available.

Functional requirements describe what the system does—for example, users can upload a photo or search products. Non-functional requirements describe how well it does it, such as latency, availability, durability, scalability, security, and cost. Non-functional requirements should be measurable where possible, such as p95 read latency below 200 ms or 99.95% monthly availability.

Start with users and activity assumptions. For example, 10 million daily active users making 20 requests each produce 200 million requests/day, or about 2,315 requests/second on average. Apply a peak factor—perhaps 3–5x—to estimate peak QPS. Estimate storage as writes per day × average record size × retention, then account for indexes, replicas, and growth. State assumptions and revise them when requirements change.

Latency is the time taken for one operation, often reported as p50, p95, and p99 percentiles. Throughput is the amount of work completed per unit time, such as requests per second. A system can have high throughput but poor tail latency if queues build up. Measure both under realistic load and consider end-to-end latency, including network and downstream calls.

An SLI is a measured indicator, such as the percentage of successful requests or p95 latency. An SLO is the target for that indicator, such as 99.9% successful requests over 30 days. An SLA is an external agreement that may specify consequences if targets are missed. Teams use SLOs and error budgets to balance release velocity with reliability work.

Remove single points of failure through redundancy across instances and, where needed, availability zones or regions. Use health checks, load balancing, automated failover, replicated data, timeouts, retries with limits, and graceful degradation. Redundancy alone is insufficient: dependencies, configuration, deployment pipelines, and control planes can still be shared failure points. Test failover regularly.

Vertical scaling increases the resources of one machine, such as CPU or RAM. It is simple but has hardware limits and may preserve a single point of failure. Horizontal scaling adds more machines or instances and distributes work among them. It improves capacity and fault tolerance but introduces coordination, partitioning, and distributed-systems complexity.

A load balancer routes incoming requests across healthy backend instances. Common strategies include round robin, least connections, weighted routing, and consistent hashing. It may terminate TLS, perform health checks, and enforce connection limits. Layer 4 balancing uses transport-level information; Layer 7 balancing can route based on HTTP paths, headers, or hostnames. Health checks should avoid declaring overloaded but live systems healthy indefinitely.

With cache-aside, the application checks the cache, reads from the database on a miss, and then populates the cache; it is simple but can serve stale data until invalidation or expiry. Write-through updates the cache and data store as part of the write path, improving cache freshness but adding latency and coordination. Write-behind updates the cache first and persists asynchronously, improving write latency but risking data loss unless the queue and persistence path are durable.