The Five Design Goals of Distributed Systems (and the Tradeoffs Nobody Mentions)

A single machine is not enough

When one server can hold all your data and answer every request in time, life is simple. Distributed systems exist because that stops being true: too many users, too much data, and a hard requirement that the service stays up even when individual machines catch fire. The moment you spread work across many computers, you inherit a set of goals to aim for, and a set of tradeoffs that make hitting all of them at once impossible.

This post walks through the five classic design goals, but with the honest part included: where they fight each other, and how real systems like Google Search, Netflix, and Nepal's Connect IPS payment gateway pick a side.

Goal 1: Scalability

Scalability is the ability to handle more work by adding more resources, without rewriting the system. It comes in two flavours worth separating:

• Vertical scaling means a bigger machine, more CPU and RAM. Simple, but there is a ceiling and a single point of failure.
• Horizontal scaling means more machines. No ceiling, but now you have to coordinate them, which is where all the hard problems live.

Google Search scales horizontally to billions of queries a day by sharding its index across thousands of machines, so each one searches a slice in parallel. Connect IPS scales to handle the spike when every bank's customers pay bills at month end. The test of good scalability is simple: if traffic doubles, can you serve it by roughly doubling the hardware, or does the design fall over?

Goal 2: Reliability and fault tolerance

In a system of thousands of machines, something is always broken. Reliability is not "nothing fails", it is "the service keeps working while things fail". The main technique is redundancy: keep more than one copy of everything, so the loss of any one copy is a non-event.

Netflix runs redundant instances across multiple data centres and famously runs Chaos Monkey, a tool that randomly kills its own servers in production to prove the system survives. Connect IPS uses failover: if a node handling transfers dies, another picks up without the user noticing. Reliability is measured in nines. "Three nines" is 99.9% uptime, about 8.7 hours of downtime a year. "Five nines" is 99.999%, about 5 minutes a year, and each extra nine costs dramatically more.

Goal 3: Transparency

Transparency means the user (and often the programmer) sees a single coherent system, not the messy cluster underneath. Distributed systems research names several kinds, and they are worth knowing because each hides a different truth:

• Access transparency: local and remote resources are used the same way.
• Location transparency: you use a resource without knowing which machine holds it.
• Replication transparency: multiple copies look like one.
• Failure transparency: partial failures are hidden and recovered from.

When you search on Google, you have no idea which of thousands of servers ranked your results, and you should not have to. When Connect IPS moves money between two banks, you see one instant confirmation, not the multi-step interbank settlement happening behind it.

Goal 4: Performance

Performance in a distributed system is dominated by one enemy: network latency. A CPU instruction takes under a nanosecond. Reading from memory takes about 100 nanoseconds. But a round trip across a continent takes tens of milliseconds, which is hundreds of thousands of times slower. Good distributed design is largely the art of avoiding unnecessary network hops.

The universal fix is to move computation and data close to the user. Netflix does this with a global CDN: your show streams from a cache in or near your city, not from a distant origin, which is why it starts in a second instead of buffering. Google returns results in milliseconds by doing the expensive ranking in parallel and caching aggressively.

Goal 5: Security

Spreading data across a network multiplies the ways it can be intercepted or tampered with. Security here rests on three pillars: confidentiality (encryption in transit and at rest), integrity (data is not altered), and availability (the system resists denial-of-service). For a payment platform like Connect IPS this is existential: transactions are encrypted, users are strongly authenticated, and every action is logged for audit.

The catch: you cannot have everything (CAP)

Here is what tidy lists of goals leave out. When the network between your machines fails, and in a big enough system it eventually will, the CAP theorem says you can keep at most two of these three:

• Consistency: every read sees the most recent write.
• Availability: every request gets an answer.
• Partition tolerance: the system keeps working despite dropped messages.

Since network partitions are a fact of life, partition tolerance is not optional, so the real choice is consistency versus availability:

• A banking system like Connect IPS chooses consistency. If two data centres cannot agree on your balance, it is safer to refuse the transaction than to risk spending the same money twice.
• A feed or catalogue like Netflix leans toward availability. If you briefly see a slightly stale list of shows, no harm done, and staying up matters more.

This is why "design goals" is not a checklist you fully satisfy. It is a set of dials, and engineering a distributed system means choosing which ones to turn up for your particular problem.

A tiny illustration of horizontal scaling

Spreading requests across machines is the everyday face of these goals. Here is round-robin distribution across three servers:

const servers = ["Server1", "Server2", "Server3"];

const handle = (server, request) =>
  new Promise(resolve =>
    setTimeout(() => resolve(`Request ${request} -> ${server}`), 200)
  );

async function distribute(requests) {
  const results = await Promise.all(
    requests.map((req, i) => handle(servers[i % servers.length], req))
  );
  console.log(results);
}

distribute([1, 2, 3, 4, 5]);
// Request 1 -> Server1, Request 2 -> Server2, Request 3 -> Server3,
// Request 4 -> Server1, Request 5 -> Server2

Even this toy shows the tradeoff in miniature: spreading load buys throughput (performance and scalability), but the instant state lives on more than one server you have a consistency problem to solve.

Takeaway

The five goals, scalability, reliability, transparency, performance, and security, are the vocabulary of system design. But the skill is not reciting them. It is knowing that pushing one often pulls another, that CAP forces a consistency versus availability decision the moment the network misbehaves, and that a bank and a video service correctly make opposite calls. Design the dials for the problem in front of you.