System Design Cheat Sheet

High availability, high throughput, and high scalability are common design goals, but teams often use the terms loosely. A useful cheat sheet is really a set of tradeoffs: what each goal means, which patterns support it, and what those patterns cost.

High availability

High availability means the service continues to operate for an agreed proportion of time. Targets such as 99.9% or 99.99% uptime are not abstract badges. They translate into an error budget for downtime and failed requests.

Availability comes from redundancy and fast failure handling. Common patterns include:

• Active-active systems where multiple instances serve traffic at the same time.
• Active-passive or hot-warm setups where a standby instance can take over quickly.
• Leader-follower clusters where one node accepts writes and replicates to others.
• Leaderless or quorum-based systems where several nodes can accept writes independently.

Each pattern makes different consistency and operational demands. Active-active improves failover speed but often needs deduplication or conflict handling. Leader-based systems simplify writes but make leader election and failover critical.

High throughput

Throughput is the amount of work the system can complete in a given period, often measured as requests per second, transactions per second, or messages per second. Improving throughput usually means removing bottlenecks from the critical path.

Typical tools include caching, batching, parallelism, connection pooling, and asynchronous processing. But more concurrency is not automatically better. Too many threads or workers can increase context switching, contention, and queue pressure.

The right question is always: what resource saturates first? CPU, memory, disk I/O, network, lock contention, or downstream dependency limits? Throughput work is mostly bottleneck analysis.

High scalability

Scalability means the system can handle more load, data, or tenants without disproportionate pain. Horizontal scaling adds more instances. Vertical scaling gives one node more capacity. Both matter, and each has limits.

A system that is scalable in theory but hard to operate in practice is not truly scalable. Stateless application tiers, partitioned data, idempotent background jobs, and automated provisioning all make scaling easier. Hidden singletons, hard-coded assumptions, and coordination-heavy components make it harder.

The goals interact

These goals are related but not identical. A system can be highly available but low throughput if it fails over cleanly yet serves only modest traffic. It can scale reads well but struggle with write consistency. It can achieve impressive benchmark throughput while being fragile during deploys.

That is why good design work treats availability, throughput, and scalability as explicit dimensions rather than one vague idea of “big system”.

Practical use

When reviewing an architecture, ask three questions. What failure can the system survive? What resource limits its throughput today? What must change when load increases by ten times?

If the design cannot answer those clearly, it does not need a prettier diagram. It needs sharper reasoning.