CodeWithYash
DSA
Spring Boot
System Design
Series
Articles
Leaderboard
Sign In

Subscribe to Newsletter

Get the latest articles, DSA sheets, and system design challenges delivered to your inbox.

<CODEWITHYASH/>

The ultimate sanctuary for software engineers seeking deep mastery of core technical principles.

Library

  • Articles
  • DSA Sheets
  • Roadmaps

Connect

  • GitHub
  • LinkedIn
  • About
  • Contact

Legal

  • Privacy
  • Terms
  • Support

© 2026 CodeWithYash Global Systems.

Status: OperationalVersion: 4.2.0
System Design
OverviewTheory lessonsHLDLLD
All SeriesSeries
Distributed Systems

System Design Series

0%

0 of 33 topics completed

Progress
Hardware Numbers Every Systems Engineer Must KnowCore
20 min
Network Protocols & Real-Time Communication ParadigmsCore
25 min
Latency vs. Throughput & The Tail at ScaleCore
25 min
Scalability Dimensions & Universal LawsCore
25 min
Availability, SLOs, SLIs & Error BudgetsCore
20 min
ACID vs. BASE & The Consistency SpectrumCore
30 min
CAP Theorem & PACELC FrameworkCore
25 min
System DesignFoundations & Mental ModelsHardware Numbers Every Systems Engineer Must Know

Foundations · Phase 1: Foundations

Hardware Numbers Every Systems Engineer Must Know

Internalize CPU register speeds, L1/L2/L3 cache misses, DRAM access times, NVMe vs SATA throughput, and datacenter vs intercontinental network latencies.

Primary specification: Latency Numbers Every Programmer Should Know (Peter Norvig)

Written & reviewed by Yash Patel 20 minBaseline 2026.1 Curated Blueprint· Verified 2026-09-14

Lesson 1 of 33

1d streak

The Architectural Question

Engineering teams design microservices without physical latency intuition, resulting in multi-hop network cascades that exhaust client connection timeouts.

Core Engineering Objectives

  • Memory hierarchy ratios (1 ns L1 vs 100 ns DRAM vs 10 µs NVMe)
  • Sequential vs random disk and memory transfer bandwidth
  • Physical speed-of-light constraints across datacenter and global fibers

1. What is it & Why it Matters

Every software system runs on physical hardware governed by fixed physical limits: CPU clock cycles, bus bandwidth, and the speed of light in optical fiber. Fetching a byte from an on-core CPU register takes under 1 nanosecond; fetching from main memory (RAM) takes ~100 nanoseconds (100x slower); reading from a high-speed NVMe SSD takes ~10 microseconds (10,000x slower); and sending a packet across an intercontinental network takes ~70 milliseconds (70,000,000x slower).

The Real-World System Design Trap

Distributed architectures fail when designers treat memory and network access as uniform, zero-cost operations. A microservice making 10 sequential cross-datacenter database calls adds 700ms of pure wire waiting time before executing a single line of business logic.

2. The Latency Numbers Every Systems Engineer Must Know

Here is the canonical latency hierarchy normalized to human perception, where 1 CPU cycle (~0.3 ns) is scaled to 1 second:

Hardware OperationReal-World LatencyHuman Scale (1 cycle = 1s)Engineering Rule of Thumb
L1 CPU Cache Reference0.5 – 1.0 ns1 – 3 secondsFastest on-chip memory. 64KB per core.
L2 / L3 CPU Cache Hit3 – 25 ns10 – 80 secondsOn-chip cache hierarchy. Stalls here are minor.
Main Memory (RAM) Read50 – 100 ns2.5 – 5 minutes100x slower than L1. DRAM stalls block CPU execution pipelines.
Sequential NVMe SSD Read (1MB)20 – 50 µs16 – 40 hoursHigh sequential bandwidth (3–7 GB/s via DMA).
Random NVMe SSD Read (4KB)10 – 25 µs8 – 20 hours100x slower than RAM, but 1,000x faster than spinning disks.
Rotational Disk (HDD) Seek4 – 10 ms5 – 12 monthsMechanical arm seek. Avoid for latency-sensitive read paths.
Same-Datacenter Network Roundtrip (LAN)250 – 500 µs9 – 18 daysLeaf-spine switch hops. Fast, but 5,000x slower than RAM.
Cross-Region WAN (US-East to EU-West)70 – 80 ms7 – 8 yearsSpeed of light in fiber (~204,000 km/s). Strict physical floor.

3. Mechanical Sympathy: Sequential vs. Random Access

Mechanical sympathy means designing software with an explicit understanding of physical hardware strengths: sequential streaming versus random pointer chasing.

Architectural Boundary · Do Not Confuse

Concept A

Sequential Memory & Disk Access (Arrays, Append Logs, LSM-Trees)

Concept B

Random Pointer Chasing (Deep Linked Lists, Unbuffered Heap Lookups)

Modern CPUs automatically prefetch contiguous memory lines, and SSDs maximize multi-gigabyte DMA burst transfer. In contrast, traversing random object references scattered across a 32GB heap forces the CPU to stall 100ns on every cache line miss.

Cache Line

The 64-byte atomic unit of data transfer between RAM and CPU. Reading even a single byte loads the surrounding 64 bytes into cache.

False Sharing

When two threads on separate CPU cores modify independent variables located on the same 64-byte cache line, causing the hardware coherency protocol to repeatedly invalidate the line across cores.

Use it when

Choose sequential append-only disk structures (WAL, Kafka logs, LSM-Trees) when designing write-heavy data systems.

Reconsider when

Avoid deep pointer-based data structures in performance-critical inner loops; prefer flat contiguous arrays or compact buffers.

4. Back-of-the-Envelope Mental Math Cheat Sheet

Back-of-the-envelope sizing is a conversation aid, not a math exam. Ask three questions: how much work arrives, how large is one item, and how much extra capacity should we keep for a burst?

StepExample: 1 million requests/dayWhy we calculate it
1. Average rate1,000,000 ÷ 86,400 ≈ 12 requests/secTurns a daily headline into work per second.
2. Burst rate12 × 3 ≈ 36 requests/secA stated 3× planning assumption makes a burst visible.
3. Daily bytes1,000,000 × 1 KB ≈ 1 GB/dayMultiplies records by their actual size.

Core Interview Rule of Thumb

Start with round numbers and write the unit beside every result. Only add replication, indexes, retries, and retention after the basic estimate is understandable.

5. Active Recall Checkpoint

Active Recall Checkpoint

Why can a sequential read from an NVMe SSD often outperform scattered random DRAM lookups in a high-throughput data pipeline?

Hint: Consider CPU prefetching, cache lines, and TLB stalls.

Show answer & explanation

Sequential SSD reads use Direct Memory Access (DMA) and OS page cache readahead to stream at 3–7 GB/s. Random heap pointer chasing misses L1/L2/L3 caches and TLB entries on every hop, forcing the CPU to stall 50–100ns waiting for DRAM on each individual node traversal.

Hardware Bounds & Sizing Math

Topic sizing snapshot

The four numbers that materially affect this architecture. Use them as bounds, not as a generic calculator embedded in every lesson.

Peak QPS

50,000 RPS

5-Yr Storage

N/A (Hardware reference)

Bandwidth

40 Gbps internal mesh

Working Set RAM

128 GB L1/L2/L3/DRAM balance

Back-of-the-Envelope Capacity Estimator

System Sizing & Scale Calculator

Compute QPS, bandwidth, replicated storage, and RAM caching requirements live.

300.0M
1M100M500M1B
100 : 1
2 KB
Retention Horizon5 Years
Query Throughput (QPS)Peak Multiplier: 3x
Average QPS

701.4Kreq/s

Reads: 694.4K/sWrites: 6.9K/s
Peak QPS (3x)

2.1Mreq/s

Peak Reads: 2.1M/sPeak Writes: 20.8K/s
Network Bandwidth
Peak Ingress (Writes)

41.67 MB/s

0.33 Gbps

Peak Egress (Reads)

4166.67 MB/s

33.33 Gbps

Total Storage Capacity5 Year Horizon
Raw Storage

1.9 PB

~398 TB / year

With 3x Replication

5.8 PB

3 Availability Zones / Replicas

Cache Memory Sizing (80/20 Rule)20% of Daily Unique Data
RAM Needed for Working Set

279 GB

Estimated Daily Unique Data: 1.1 TB

Includes 25% metadata and capacity headroom

Production Postmortem & Verification

Production Incident Postmortem

  1. Trigger / Setup: A payment service makes 14 sequential internal RPCs across regions during a single user checkout transaction.
  2. Production Symptom: Transaction latency exceeds 1,400ms, triggering client-side timeouts and duplicate payment charge attempts.
  3. Root Cause & Fix: Cross-region RTT (70ms) sets a hard physical floor; fanout must be minimized or executed in parallel with strict deadlines.

Acceptance Criteria & Outcomes

  • Quantify nanosecond, microsecond, and millisecond tiers across compute, storage, and networking.
  • Differentiate sequential read bandwidth from random access latency across memory, NVMe SSD, and spinning disk.
  • Demonstrate how network round-trip times dominate server-side compute in distributed request paths.

End-of-Chapter Synthesis & Key Takeaway

Hardware Numbers Every Systems Engineer Must Know is built around one fundamental rule: Establish clear responsibility and explicit trade-offs.. Before adding components, establish explicit quantitative SLAs for latency, throughput, and consistency. Choose the simplest architecture that meets stated constraints.

Architectural & Technical Interview Review

Core FAANG Interview Questions

3 Questions
Q01
How do you justify introducing Hardware Numbers Every Systems Engineer Must Know into a high-scale production architecture?
Click to reveal model answer →Hide answer ↑Requirements & Design Brief

Introduce Hardware Numbers Every Systems Engineer Must Know only when measured scale, data size, or failure boundaries exceed single-node capacity. State the exact bottleneck, evaluate operational overhead, and verify that the trade-offs justify the added moving parts.

Source section: Requirements & Design Brief
Q02
What is the primary trade-off and hidden operational cost of Hardware Numbers Every Systems Engineer Must Know?
Click to reveal model answer →Hide answer ↑Architecture Trade-offs

It improves scalability and availability, but introduces network hops, serialization overhead, and eventual consistency or coordination complexity.

Source section: Architecture Trade-offs
Q03
How do you handle catastrophic failure or dependency degradation in Hardware Numbers Every Systems Engineer Must Know?
Click to reveal model answer →Hide answer ↑Failure Review & Recovery

Implement connect/read timeouts, exponential backoff with jitter, and fallback defaults so downstream degradations do not cause cascading outages.

Source section: Failure Review & Recovery

Production Pitfalls & Anti-Patterns

Critical Failure Anti-Patterns

!

Premature Distributed Complexity

Scattering distributed components before identifying concrete write, read, or storage limits creates accidental points of failure and operational debt.

Production Mitigation: Start with the simplest modular design that satisfies requirements, evolving it only as measured constraints dictate.

!

Unbounded Retries and Cascading Storms

When a dependency degrades, immediate synchronized retries multiply downstream traffic, turning a minor slowdown into a total fleet outage.

Production Mitigation: Enforce strict retry budgets, exponential backoff, and full randomized jitter on all client calls.

!

Neglecting Observability and Metrics

Deploying architecture without distributed tracing or p99 tail latency alerts leaves engineers blind when partial partitions occur.

Production Mitigation: Export metrics for request rate, error rate, p95/p99 duration, and saturation at every service boundary.

Primary Documentation & Specifications

Latency Numbers Every Programmer Should Know (Peter Norvig)Designs, Lessons and Advice from Building Large Distributed Systems (Jeff Dean)
Next LessonNetwork Protocols & Real-Time Communication ParadigmsFoundations

In this chapter

01Architectural Question021. What is it & Why it Matters032. The Latency Numbers Every Systems Engineer Must Know043. Mechanical Sympathy: Sequential vs. Random Access054. Back-of-the-Envelope Mental Math Cheat Sheet065. Active Recall Checkpoint07Capacity Estimator08Production Verification09Synthesis & Review10Primary References

Chapter promise

Memory hierarchy ratios (1 ns L1 vs 100 ns DRAM vs 10 µs NVMe)