System Design Basics

advanced2 min read

Node.js

Thinking about how the big pieces of a system — clients, servers, databases, caches, load balancers — fit together, and reasoning about the tradeoffs between them.

What you'll understand

What system design is concerned with
The common building blocks of a system
Why system design is about tradeoffs, not right answers

Explanation

System design is the high-level view: instead of how one function works, it asks how the major components of a whole system fit together to meet requirements. It zooms out from a single service to the arrangement of clients, servers, databases, caches, queues, and the connections between them, and how they cooperate to serve users reliably.

A handful of building blocks recur in most designs. Clients talk to application servers, often through a load balancer that spreads traffic across several instances (see Related Topics on reverse proxies and scalability). Servers read and write a database, and a cache in front of it holds hot data to reduce load and latency. Message queues let parts of the system communicate asynchronously so slow work does not block a request. Knowing what each piece is for lets you assemble them to fit a problem.

The defining truth of system design is that there is no single right answer, only tradeoffs. Adding a cache improves speed but introduces staleness; splitting into more services improves independence but adds operational complexity; optimising for consistency can cost availability. Good design starts from the actual requirements, how much traffic, how much data, how much latency is acceptable, and chooses deliberately, making the tradeoffs explicit rather than reaching for the most complex option.

Examples

A common web-system shape assembles a few standard building blocks:

Clients
   -> Load Balancer
        -> App Servers (many instances)
             -> Cache   (fast reads of hot data)
             -> Database (source of truth)
             -> Queue   (async/background work)

Common mistakes

Designing for imagined massive scale a system will never reach.
Adding components (caches, queues, services) without a requirement that justifies them.
Ignoring the tradeoffs a choice brings, such as cache staleness.
Starting from a favourite architecture instead of from the requirements.

Best practices

Start from real requirements: traffic, data volume, and acceptable latency.
Understand what each building block is for before adding it.
Make tradeoffs explicit and choose deliberately.
Prefer the simplest design that meets the requirements (see Related Topics).