HLD Cheat Sheet

By the Syncfusion DevTutorials team · Last updated October 20, 2026

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:

Going from 50% to 90% busy makes the average wait five times longer: 20 ms to 100 ms. At 95% it doubles again to 200 ms.

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.