# HLD Cheat Sheet

Course: [High-Level Design](https://www.devtutorials.ai/learn/system-design/hld) · Section: HLD Case Studies
Source: https://www.devtutorials.ai/learn/system-design/hld/case-studies/hld-cheat-sheet

> Every number, formula, building block and pattern from High-Level Design on one page: latency, estimation, capacity, the four checks and common trade-offs.

This page collects the numbers, formulas and patterns from the whole High-Level Design tutorial in one place. Use it before a design review or an interview, or whenever you need a number fast. Each row points back to the lesson that explains it.

## The Design Loop

Every design in this tutorial followed the same five steps (Lesson 1, and every case study).

| Step | Ask | Output |
|---|---|---|
| 1. Requirements | What must it do? How well? What is out of scope? | Functional list, non-functional targets (p99, availability, budget) |
| 2. Estimate | How many requests, how much data, how much bandwidth? | Reads/s and writes/s at peak, storage per year, Gbit/s |
| 3. Design | Which parts, connected how? | A diagram with a read path and a write path |
| 4. Check | Does it meet the targets at peak, after one failure, within budget? | Pass or fail, with the busiest part named |
| 5. Trade-offs | What did you give up? What breaks first at 10 times the size? | A short list of decisions and their costs |

## Numbers to Know

### Latency (Lesson 3)

| Action | Time | If memory read = 1 second |
|---|---|---|
| Read from memory | 100 ns | 1 s |
| Read from SSD | 150 µs | about 25 minutes |
| Round trip inside a data centre | 0.5 ms | about 1.4 hours |
| Hard disk seek | 10 ms | about 28 hours |
| Round trip to another continent | 150 ms | about 17 days |

### Time and Traffic (Lesson 2)

| Fact | Value |
|---|---|
| Seconds in a day | 86,400 (round to 100,000 for quick sums) |
| 1 million requests a day | about 12 a second on average |
| Peak factor | busiest second is often 2 to 10 times the average |
| Bits and bytes | 1 byte = 8 bits; network speeds are in bits |

### Availability (Lesson 1)

| Target | Down per year | Down per month |
|---|---|---|
| 99% | about 3.7 days | about 7.3 hours |
| 99.9% | about 8.8 hours | about 44 minutes |
| 99.99% | about 53 minutes | about 4.4 minutes |

## Formulas

A worked example: 1 million events a day, a peak factor of 5, 500 bytes each kept for 5 years in 3 copies, and 50 KB per response.

| Estimate | Working | Result |
|---|---|---|
| Average rate | 1,000,000 ÷ 86,400 | 11.6 a second |
| Peak rate | 11.6 × 5 | 58 a second |
| Storage | 1,000,000 × 365 × 5 × 500 bytes × 3 | 2.74 TB |
| Bandwidth at peak | 58 × 50 KB × 8 | 0.02 Gbit/s |

| What | Formula | Lesson |
|---|---|---|
| Average rate | per day ÷ 86,400 | 2 |
| Peak rate | average × peak factor | 2 |
| Storage | items × size × days kept × copies | 2 |
| Bandwidth | peak requests × response size × 8 | 2 |
| Servers needed | peak ÷ per-server capacity, + 1 spare (+ more to stay under ~70% busy) | 4 |
| Busy (utilisation) | arrival rate ÷ capacity; above about 80–90%, waits grow fast | 4, 11 |
| Average read time with a cache | hit × cache time + (1 − hit) × database time | 5 |
| Reads that reach the database | requests × (1 − hit ratio) | 5 |
| Quorum overlap | W + R > N means every read sees the latest write | 8 |
| Error budget | (100% − SLO) × requests | 1, 12 |
| Burn rate | current error rate ÷ error budget rate | 12 |
| Code length (base62) | smallest k with 62^k ≥ total items | Case: URL shortener |
| Connections per gateway | online users ÷ connections per gateway, + 1 spare | Case: Chat |

The chart shows how fast waiting grows as one server gets busy, when each request needs 10 ms of work:

This is why the case studies keep every tier comfortably below 90% busy, even after one machine is lost.

## Building Blocks

| Part | Use it for | Watch out for | Lesson |
|---|---|---|---|
| Load balancer | Spreading requests over servers | It is a single point of failure: run two | 4 |
| Cache | Hot, read-heavy data | Stampedes, stale data, losing a node | 5 |
| Database leader + followers | Durable data; followers for reads | Writes all go to one leader | 6 |
| Partitioning (sharding) | Data or writes too big for one machine | Hot keys, re-sharding | 7 |
| Quorums | Tuning consistency against speed | W + R > N for strong reads | 8 |
| Queue | Slow or bursty work, decoupling | At-least-once delivery: make work idempotent | 9 |
| Rate limiter | Protecting services from floods | Shared counters, fail open | 10 |
| Timeouts, retries, breakers | Surviving slow or failing dependencies | Retry storms: back off with jitter | 11 |
| Metrics, logs, traces | Seeing what is wrong, and where | Alert on symptoms, not causes | 12 |
| Object storage | Files of any size | Keep details in a database row | Case: File storage |
| CDN | Files and segments for many users | Give changed files new names | Case: File storage, Video |
| Pub/sub | Routing messages to the right server | Offline receivers need saved messages | Case: Chat |

## Pattern to Problem

| Problem you see | Pattern to reach for | Case study |
|---|---|---|
| Same data read again and again | Cache-first read path | URL shortener |
| Many small writes on every read | Move the write to a queue | URL shortener (click counts) |
| Bots or scripts flooding an endpoint | Shared rate limiter, fail open | Rate limiter service |
| Expensive reads that combine many sources | Precompute on write (fan-out), hybrid for giants | News feed |
| Server must push to a client | WebSockets + pub/sub routing | Chat |
| Too many writes for one leader | Partition by a key that keeps related data together | Chat |
| Slow outside providers | Queue per channel, retries with dedupe keys | Notification system |
| Large files | Object storage, presigned uploads, CDN | File storage |
| Very high request rate, tiny answers | Precomputed index in memory, debounce, cache | Search autocomplete |
| Money or anything that must happen once | Idempotency keys, state machine, ledger, reconciliation | Payments |
| Heavy background jobs that must finish soon | Split into chunks, run in parallel | Video streaming |
| Expensive, slow compute per request | Stream results, batch work, cache answers | LLM inference serving |

## The Four Checks

Every case study design was graded the same way. Use the same list in a real design review.

| Check | Question | Typical fix when it fails |
|---|---|---|
| Peak load | Does p99 meet the target at the busiest second? | Cache, more machines on the busiest tier, move work to a queue |
| Lose any one machine | Does anything fall over when one box dies? | A spare of every kind; replicas; two cache nodes |
| Cost | Is it within budget? | Remove spares that are not needed; use the cheapest part that does the job |
| Requirements | Are the non-speed rules met (no double charges, unique codes, counted clicks)? | Idempotency keys, queues, the right redirect, ID ranges |

In an interview, say the four checks out loud as you go: "At peak this tier is about 70% busy. If one server dies it goes to about 90%, so I add a spare. That costs one more server a month." That one sentence shows estimation, failure thinking and cost.

## Common Trade-offs

| Choice | You gain | You give up |
|---|---|---|
| Cache | Speed, less database load | Possible stale data, one more thing to fail |
| Replicas for reads | Read capacity, survival | Replication lag: followers can be behind |
| Strong consistency | Always-correct reads | Latency, and availability during partitions |
| Queue | Fast answers, smooth bursts | The work finishes later; must handle duplicates |
| Push (fan-out on write) | Cheap reads | Expensive writes, especially for huge accounts |
| 301 redirect | Less traffic | Clicks you cannot count |
| Fail open | Availability | Brief loss of protection |
| Batching | Throughput | A little more delay per item |

## Common mistakes

| Mistake | Wrong | Correct | Why it happens |
|---|---|---|---|
| Designing before estimating | Boxes first, numbers never. | Requirements, then estimates, then design. | Drawing is more fun than arithmetic. |
| Averages only | "Average 40 ms, we are fine." | Use p99 and the peak second. | Averages hide the slowest users and the busiest minute. |
| No spare | Exactly enough machines for peak. | Peak plus one of each kind, below about 90% busy after a loss. | It meets the target on paper. |
| One of anything | A single load balancer, cache node or leader. | Two, or a clear plan for losing it. | Single parts work perfectly until they do not. |
| Retrying without a key | Retries that repeat side effects. | Idempotency keys on every retried action. | Retries are added later as a quick fix. |

All numbers here are the ones used in this tutorial's lessons and simulators. Real systems differ; the point is the order of magnitude and the habit of checking, not the exact value.

## Further Reading

- [Google SRE Book](https://sre.google/sre-book/table-of-contents/): SLOs, monitoring and reliability in practice.
- [System Design Primer](https://github.com/donnemartin/system-design-primer): a broad reference of components and worked designs.
- [Latency numbers every programmer should know (interactive)](https://colin-scott.github.io/personal_website/research/interactive_latency.html): latency figures and how they changed over the years.