SysDesign Core · Capstone series
The capstone of the sharpbyte.dev learning series—tying together Unix, Java, Spring, Microservices, Kafka, Docker, K8s, and DevSec into real-world architectural decision-making. Not boxes and arrows: why each choice is made, what breaks at scale, and how elite engineering teams think. Part of the broader System design topic—pair with product case studies and interview prompts when you are ready to apply the theory.
Junior engineers implement features. Senior engineers design systems that survive traffic spikes, partial failures, and organizational change. System design is the discipline of making architectural decisions under constraints—latency, cost, consistency, team size, and time.
Interviews test this skill because production doesn't forgive naive architecture. A URL shortener that works for 100 users collapses at 100M. A Twitter feed that fan-outs on write for every user dies when Katy Perry tweets. The difference between L4 and L6 isn't knowing more patterns—it's trade-off reasoning with real numbers.
Great system designers operate on two axes simultaneously. Breadth without depth produces shallow diagrams. Depth without breadth produces over-engineered solutions to simple problems.
CQRS, sharding, consistent hashing, saga, fan-out on write, circuit breaker, cache-aside, leader election. Recognize the pattern when you see the problem. A rate limiter needs token bucket; a feed needs hybrid fan-out.
Why Cassandra over MySQL for this write pattern? Why p99 matters more than average latency? Why 2PC fails across microservices? Why Redis SETNX locks need fencing tokens? Depth is what interviewers probe in the deep-dive phase.
L5 candidates name patterns. L6 candidates explain when not to use them and quantify the cost. "We'll use Redis" is L4. "Redis cache-aside with 5-minute TTL, mutex on miss to prevent stampede, ~100K ops/sec per node—at 35K read QPS we need one cluster with headroom" is L6.
Toggle Learning or Interview in the nav (saved in your browser). Content sections tagged for each track appear or hide globally across every page.
Learning track
Distributed systems theory, database internals, real production numbers, and how Netflix, Uber, and Discord actually solved these problems. Read sequentially or dive into weak areas.
Interview track
RADIO framework, 45-minute time allocation, estimation templates, red flags / green flags, and level-specific expectations for FAANG/MANGA L4 through Principal.
Read fundamentals → databases → caching → distributed systems in order for the learning track. For interview prep, start with Interview Framework and Case Studies, then backfill theory where your deep-dives feel thin.
Switch to Interview mode before mock sessions. Hide deep theory, surface frameworks and time-boxed templates. Practice saying assumptions out loud: "300M DAU, 10 reads/day, peak 3× average—that's ~35K read QPS."
Problems scale with level. L4 tests fundamentals and happy path. L6 tests failure modes, cross-cutting concerns, and org-level trade-offs. Match your preparation to your target level.
Preparing only for L4 problems leaves you underprepared for senior loops—interviewers will push into failure modes and scale. Preparing only for L6 problems wastes time if you're targeting mid-level. Use level badges throughout the guide to focus effort.
Every system design answer follows the same skeleton. RADIO keeps you structured under time pressure and ensures you don't skip non-functional requirements or trade-offs.
Functional, non-functional, explicit out-of-scope
High-level components, data flow diagram
Schema, indexes, access patterns, shard key
Key APIs, request/response, pagination
Bottlenecks, caching, sharding, trade-offs
Full templates, requirement questions, and deep-dive decision trees in Interview Framework →
Time-box ruthlessly. Candidates who spend 20 minutes on requirements never reach architecture. Candidates who skip estimation guess wrong on every component count.
Clarify functional scope, DAU/QPS, latency, consistency, out-of-scope. Ask questions.
Back-of-envelope: QPS, storage, bandwidth, server count. State assumptions aloud.
Draw boxes: client, LB, API, cache, DB, queue, workers. Explain data flow.
Interviewer picks: DB schema, cache strategy, fan-out, consistency, API design.
10× traffic, single points of failure, monitoring, trade-offs summary.
Starting to draw before clarifying requirements is the #1 red flag. Passive silence while drawing is #2. Think out loud—interviewers score your reasoning process, not just the final diagram.
SysDesign Core assumes you've worked through—or can reference—these sharpbyte.dev series. System design sits on top of runtime, networking, and delivery fundamentals.
Every non-functional requirement maps to one of these pillars. Great designs optimize across all eight— not maximally on one at the expense of others.
Handle growth in users, data, and traffic—vertically or horizontally.
Correct behavior under expected conditions; fault tolerance when components fail.
System is up when users need it—nines, MTBF, MTTR, redundancy.
Teams can evolve the system—operability, simplicity, extensibility.
Latency (p50/p99) and throughput—often in tension with each other.
Dollars per request, storage tiering, right-sizing—not over-provisioning by default.
AuthN/Z, encryption, rate limiting, abuse prevention, data residency.
Four golden signals, SLOs, tracing—know when and why things break.
Google SRE codified the four golden signals: latency, traffic, errors, saturation. Netflix prioritizes availability and graceful degradation over strong consistency for streaming metadata. Stripe inverts that—financial correctness demands strong consistency even at latency cost.
Thirteen chapters from fundamentals to cheat sheets. Recommended learning path: Fundamentals → Networking → Databases → Caching → Distributed Systems → Case Studies.
Learning path: Fundamentals · Databases · Caching · Distributed Systems · Case Studies
Interview path: Interview Framework · Case Studies · Cheat Sheets · Patterns Library
Latency numbers, throughput vs latency, scalability, CAP, PACELC, consistency models, back-of-envelope estimation.
HTTP/2, HTTP/3, gRPC, WebSockets, SSE, API design, pagination, rate limit headers.
LB algorithms, L4 vs L7, reverse proxy, API gateway, health checks, global load balancing.
RDBMS, sharding, NoSQL families, replication, selection framework—the most critical design page.
Cache placement, eviction, invalidation, stampede prevention, distributed cache, CDN.
Consensus, locks, transactions, clocks, leader election, failure detection, CRDTs.
Queue vs stream, Kafka vs RabbitMQ vs SQS, backpressure, ordering, delivery guarantees.
Fan-out on write vs read, CQRS, event sourcing, Lambda/Kappa, partitioning strategies.
8 deep dives: URL shortener, rate limiter, KV store, Twitter, YouTube, Uber, WhatsApp, Google Maps.
RADIO, 45-minute clock, estimation template, deep-dive framework, level expectations.
Visual catalog: scalability, reliability, data, messaging, deployment, distributed patterns.
Fundamentals, database selection, interview templates—copy-to-clipboard quick references.
