Docs / System Design Interview / Fundamentals

System Design Fundamentals

System design interviews evaluate whether you can reason about systems at the level of a senior engineer — making tradeoffs, communicating clearly, and avoiding fatal architectural mistakes. The fundamentals below are the vocabulary you need before you can have that conversation.

The vocabulary

Scalability

A system is scalable if you can handle more load by adding more resources. Vertical scaling means a bigger machine; horizontal scaling means more machines. Horizontal almost always wins at interview scale because it's cheaper, fault-tolerant, and avoids hardware ceilings.

Latency vs throughput

  • Latency — time for a single request to complete.
  • Throughput — number of requests handled per unit time.

You can have low latency and low throughput (a single fast server), or high throughput and high latency (a batch processing system). Interviewers care about which you're optimizing.

CAP theorem

In a distributed system, when there's a network partition, you choose between Consistency and Availability — you can't have both at the same time. In practice this is a spectrum, not a binary choice. Most real systems pick AP and engineer around eventual consistency.

Consistency models

  • Strong — every read sees the latest write. Expensive.
  • Eventual — reads may be stale, but converge. Cheap and scalable.
  • Causal / read-your-writes — middle ground. Often what users actually want.

Building blocks

These six come up in nearly every system design interview:

  1. Load balancer — distributes requests. L4 (TCP) vs L7 (HTTP). Round-robin, least-connections, consistent-hashing.
  2. Cache — reduces latency and load on the database. Read-through, write-through, write-behind. Cache invalidation is famously hard.
  3. Database — SQL for transactions and joins; NoSQL when scale matters more than consistency.
  4. Message queue — decouples producers from consumers. Kafka and RabbitMQ are the canonical examples.
  5. CDN — pushes static content to the edge.
  6. Object storage — for large blobs (S3, GCS).

If you can sketch a system using these six, you can pass most interviews.

What "good" looks like

A strong system design candidate does three things:

  1. Asks clarifying questions before drawing anything. Scale? Read-heavy or write-heavy? Latency targets?
  2. Starts simple, then scales. A single-server design first, then identify bottlenecks, then scale them out.
  3. States tradeoffs explicitly. "I'd use Cassandra here. We give up strong consistency, but we get write throughput and partition tolerance, which matters more for this workload."

That's the whole interview. Practice each of those three habits separately until they're automatic.