System Design Core Principles Cheat Sheet
Master quick-reference guide for system architects covering High Availability (HA), High Scalability, High Throughput, and latency mitigation trade-offs.
Master quick-reference guide for system architects covering High Availability (HA), High Scalability, High Throughput, and latency mitigation trade-offs.
1. High Availability (HA) Cheat Sheet
High Availability ensures an agreed level of operational uptime. Availability is measured in "nines":
| Availability Tier | Downtime per Year | Downtime per Month | Downtime per Day | Typical System Architecture |
|---|---|---|---|---|
| 99% (Two Nines) | 3.65 days | 7.20 hours | 14.4 minutes | Single instance, manual backup restore |
| 99.9% (Three Nines) | 8.76 hours | 43.8 minutes | 1.44 minutes | Multi-AZ standby, automated failover |
| 99.99% (Four Nines) | 52.6 minutes | 4.38 minutes | 8.64 seconds | Multi-AZ active-active, auto-healing |
| 99.999% (Five Nines) | 5.26 minutes | 25.9 seconds | 864 milliseconds | Multi-region active-active with global consensus |
Redundancy & Clustering Strategies
Interactive Architecture DiagramSynthesizing vector architecture diagram...
| Strategy | Architecture Model | Pros | Cons (Failure Modes) | Recommended Use Case |
|---|---|---|---|---|
| Hot-Hot (Active-Active) | Both nodes serve production traffic concurrently. | Zero failover time, full capacity utilization. | Write-write conflict resolution, dual write deduplication. | Global APIs, Payment Gateways, WebSocket Routers |
| Hot-Warm (Active-Passive) | Primary node serves traffic; standby receives replication stream. | Predictable consistency, simpler disaster recovery. | Failover lag (30-60s DNS/Route53 cutover), idle capacity cost. | Relational DBs (Aurora Standby, Redis Replica) |
| Single-Leader Cluster | Single leader processes writes; multiple read-replicas scale reads. | Strict serializability for writes, horizontally scalable reads. | Leader is write bottleneck; replication lag creates stale reads. | PostgreSQL / MySQL Clusters, OpenSearch Primary |
| Leaderless Cluster (Quorum) | Any node handles read/write; uses Dynamo-style W + R > N quorum. | No single point of failure, exceptional write availability. | Eventual consistency, vector clocks, read repair overhead. | DynamoDB Global Tables, Apache Cassandra |
2. High Scalability Cheat Sheet
Scalability defines the capability of a system to handle increasing loads without degradation in response time or failure rates.
Vertical vs. Horizontal Scaling Trade-Offs
| Scaling Dimension | Vertical Scaling (Scale Up) | Horizontal Scaling (Scale Out) |
|---|---|---|
| Mechanism | Add CPU cores, RAM, and NVMe drives to a single box. | Add more distributed instances behind a load balancer. |
| Hardware Limit | Hard physical limit (e.g. AWS u-24tb1.metal instance caps). | Virtually limitless horizontal partition expansion. |
| Complexity | Extremely simple; zero code refactoring required. | Requires state externalization, hashing rings, and sharding. |
| Cost Curve | Exponential cost curve as instance sizes reach upper limits. | Linear or sub-linear cost via commodity cloud compute. |
| Downtime | Requires restart/downtime during instance upgrades. | Rolling zero-downtime blue/green deployments. |
Data Partitioning Strategies
Interactive Architecture DiagramSynthesizing vector architecture diagram...
- Range-Based Partitioning:
- Keys clustered by ordered ranges (e.g., date
2026-09, alphabetA-C). - Risk: Hotspots on recent timestamps or popular prefixes.
- Keys clustered by ordered ranges (e.g., date
- Consistent Hashing:
- Hash key mapped onto a 360-degree integer circle with virtual nodes.
- Advantage: When adding or removing a node, only K/N keys must be remapped.
- Directory-Based Sharding:
- Lookup service or central registry maps partition keys to database shards.
- Advantage: Arbitrary placement flexibility, but lookup table becomes a critical path single point of failure.
3. High Throughput & Latency Mitigation
High throughput systems optimize for query per second (QPS) and transactions per second (TPS) while keeping p95/p99 latency bounded.
Latency Numbers Every System Architect Must Know
| Operation | Typical Latency | Human-Scale Metaphor |
|---|---|---|
| L1 CPU Cache Reference | 0.5 ns | 1 heartbeat |
| L2 CPU Cache Reference | 7 ns | 14 heartbeats |
| RAM Memory Access | 100 ns | 3.3 minutes |
| NVMe SSD Sequential Read (1MB) | 250 µs | 5.8 days |
| NVMe SSD Random Read | 100 µs | 2.3 days |
| Same-Datacenter Network Round-Trip | 500 µs | 11.6 days |
| Cross-Continent Network Round-Trip (SF to NYC) | 40 ms | 2.5 years |
| Cross-Ocean Network Round-Trip (SF to HK) | 150 ms | 9.5 years |
Architectural Levers for High Throughput
- Multi-Tier Caching:
- Edge: CDN (CloudFront) for static assets and API cache-control headers.
- Gateway: In-memory reverse proxy cache (Envoy / NGINX).
- Application: Redis cluster / ElastiCache for warm database objects.
- Asynchronous Non-Blocking I/O:
- Defer compute-heavy jobs (video transcoding, PDF generation, email blasts) via message queues (SQS, Kafka).
- Batching & Pipelining:
- Group single database writes into atomic batch operations (e.g.,
BatchWriteItemin DynamoDB or multi-row SQL inserts). - Pipeline Redis requests to avoid per-command network round-trip overhead.
- Group single database writes into atomic batch operations (e.g.,
- Connection Pooling:
- Reuse TCP/TLS connections via RDS Proxy or Envoy to eliminate expensive 3-way handshakes and TLS negotiation penalties.
4. Key Primitives Cheat Sheet Cross-References
Accelerate your understanding by pairing this cheat sheet with our core architectural primitives:
- Distributed Cache — Cache-aside, write-through, and cache stampede protection.
- Distributed Rate Limiter — Token bucket, sliding log, and Redis cell algorithms.
- Message Queue — At-least-once delivery, dead-letter queues, and FIFO ordering.
- Database Sharding & Replication — Master-slave failover, partition keys, and dual-write mitigations.