A COMPLETE PATH · 100 HOURS
System design.
Clearly.
Understand the concepts. Draw the system.
Explain every decision with confidence.
A fresh, focused course with 63 chapters, 15 complete designs, and a repeatable interview method. Simple language. Serious depth.
Your study progress stays in this browser.
THE INTERVIEW FRAMEWORK01 — 07
- 01Clarify the requirementsFunctional scope + nonfunctional targets
- 02Estimate the scaleBack-of-the-envelope calculations
- 03Define the APIRequests, responses and retries
- 04Define the data modelRecords, keys and access patterns
- 05Draw the high-level designThe smallest complete working system
- 06Go deepScale a measured bottleneck
- 07Find bottlenecks and failure pointsRecovery, security and trade-offs
Start with requirements.
Make each design choice explainable.
100hguided study & practice
63focused chapters
630questions with explanations
1–2hcomplete revision path
LEARN IT ONCE. REASON IT THROUGH.
A small loop.
A lasting understanding.
- 01Read & trace
Clear explanations and labelled diagrams show the mechanism.
- 02Draw & apply
Work a concrete exercise, then compare the developed solution.
- 03Recall & check
Retrieve the key ideas. Finish ten questions and get your score.
YOUR 100-HOUR ROADMAP
One chapter at a time.
The budget includes reading, drawing, exercises and quizzes. It is a study plan, not a promise about learning speed.
01Think like a designer6 hours02Understand the building blocks18 hours03Make the right trade-off23 hours04Design complete systems50 hours05Bring it all together3 hours
How difficulty is graded
- Beginner
- Explain a building block or work a basic estimate.
- Intermediate
- Choose and apply an approach under concrete workload and correctness constraints.
- Advanced
- Coordinate components and shared state under scale, concurrency and failures.
63 chapters · 100 hours
01
Think like a designer
Frame the problem before choosing the parts.
- 01What a system design interview measuresLearn to turn an ambiguous product request into a defensible technical proposal.
- 02A repeatable interview processUse a flexible sequence that keeps requirements, architecture, and deep dives connected.
- 03Functional and non-functional requirementsTranslate a product idea into observable operations, quality targets, and correctness rules.
- 04Back-of-the-envelope estimationEstimate traffic, storage, and bandwidth using explicit assumptions and consistent units.
- 05A practical system design templateUse one reusable outline while tailoring the depth to each product’s hardest requirement.
- 06Common interview mistakes and how to recoverRecognize reasoning traps early and recover by reconnecting the design to its requirements.
02
Understand the building blocks
Trace what each component does, and where it fails.
- 07System design building blocksFollow one request through compute, storage, networking, and background work.
- 08Characteristics of distributed systemsDistinguish scalability, availability, reliability, durability, and fault tolerance using observable promises.
- 09Load balancingDistribute requests across healthy capacity while preserving deadlines and safe failure behavior.
- 10Load balancing algorithmsChoose a routing policy using request cost, connection lifetime, and placement needs.
- 11Forward and reverse proxiesUnderstand who a proxy represents and how trust, caching, and routing cross its boundary.
- 12Caching fundamentalsUse cached copies to reduce work while defining freshness, invalidation, and miss behavior.
- 13Database indexesChoose indexes from query shapes and understand their storage and write costs.
- 14Data partitioningSplit data using keys that support the access pattern while planning skew and cross-partition work.
- 15Consistent hashingKeep key placement more stable when nodes change while treating balance and durability as separate concerns.
- 16Redundancy and replicationUse extra capacity and data copies to survive stated failures without confusing replicas with backups.
- 17CAP: consistency and availability during partitionsUse a disconnected write-and-read timeline to explain the CAP limit and choose safe behavior for each operation.
- 18PACELC: normal-operation latency trade-offsCompare what reads and writes wait for during normal communication, then define their behavior when communication fails.
- 19Read and write quorumsUse set intersection correctly while recognizing that arithmetic alone does not establish linearizability.
- 20Leader and follower replicationPut a group’s writes in order while checking what followers have applied and how a replacement safely takes over.
- 21Heartbeats and failure suspicionUse periodic signals to detect missing progress while keeping failure detection separate from safe authority.
- 22Checksums and data integrityDetect changed bytes with checksums while separating accidental corruption from authenticity.
- 23Bloom filtersUse a small bit array to avoid expensive absent-key lookups while keeping exact records and decisions in the database.
- 24Polling, long polling, WebSockets, and server-sent eventsChoose a real-time transport from direction, update frequency, recovery, and operational constraints.
03
Make the right trade-off
Choose with a reason. Name the cost.
- 25Discussing tradeoffs clearlyTurn competing requirements into a justified decision that can change when evidence changes.
- 26Latency versus throughputSeparate how long one operation takes from how many operations the system completes.
- 27Horizontal versus vertical scalingChoose between larger machines and more machines by identifying the resource and coordination bottlenecks.
- 28Forward proxies versus reverse proxiesFollow the company and store proxies to see whose connections they control and what the API must still check.
- 29CDN delivery versus direct origin servingDecide when nearby reusable copies justify a CDN, and protect the original files and private access.
- 30Load balancer versus API gatewaySeparate distributing traffic from applying API policies while recognizing that products can do both.
- 31API gateway versus direct service exposureDecide whether clients coordinate service calls directly or a gateway assembles them, including partial failures and deadlines.
- 32Token bucket versus leaky bucketControl bursts and steady work deliberately, including atomic accounting and overload behavior.
- 33Stateful versus stateless architectureChoose where carts, sessions and connection progress live so another worker can recover them after a failure.
- 34Serverless versus server-based executionCompare provider-managed execution with your own worker fleet using traffic, processing time, cost and recovery needs.
- 35REST versus remote procedure callsCompare resource APIs with named commands, then specify fields, results and safe retries for either style.
- 36Synchronous versus asynchronous communicationDecide what must finish before responding and make delayed work visible, durable, and retryable.
- 37Push versus pull architectureChoose who initiates delivery based on freshness, consumer control, fanout, and recovery.
- 38Polling, long polling, WebSockets, and webhooksSelect a concrete delivery mechanism and define authentication, connection cost, and missed-message recovery.
- 39Batch versus stream processingChoose data-processing boundaries by result freshness, event timing, recovery, and cost.
- 40SQL versus NoSQL data storesChoose a data model and guarantees from access patterns rather than database stereotypes.
- 41Normalization versus denormalizationKeep current facts in one place where practical, and explain how any copied display values stay correct.
- 42ACID and BASE database propertiesFollow a transfer to separate all-or-nothing balance changes from a delayed activity display.
- 43Strong versus eventual consistencyExplain which saved version a read may return, then show the coordination and failure behavior each promise requires.
- 44Primary-replica versus peer replicationExplain which replicas may accept writes, how conflicts are resolved, and what happens when the current writer fails.
- 45Read-heavy versus write-heavy workloadsCount the work behind each read and write, including popular keys and copied views, before choosing an optimization.
- 46Client-side versus server-side cachingPlace cached copies where they save the intended work without crossing identity or freshness boundaries.
- 47Cache-aside, read-through, write-through, and write-backShow who loads missing copies, how edits race with refills, and where accepted buffered writes must survive a crash.
04
Design complete systems
Fifteen problems. One repeatable interview process.
- 48Design a URL shortener (TinyURL)Build unique short links, open them quickly and keep expiry, disabling and private access working as visits grow.
- 49Design a text-sharing service (Pastebin)Publish shareable text, check private access and expiry, and separate body downloads from the database that stores paste details.
- 50Design a photo-sharing service (Instagram)Let authors publish complete photos and followers browse them, then separate image delivery from the work of building feeds.
- 51Design a file synchronization service (Dropbox)Keep complete file versions in sync across devices, resume failed transfers and preserve conflicting offline edits.
- 52Design a messaging service (Facebook Messenger)Save each intended message once, recover missing messages on offline devices and distinguish saved, delivered and read receipts.
- 53Design a microblogging service (Twitter)Publish short posts and build follower feeds, using prepared lists for ordinary authors and read-time merging for large audiences.
- 54Design a video service (YouTube or Netflix)Prepare several video quality levels so the player can adjust when download speed falls, and deliver segments without making catalog or encoding work delay playback.
- 55Design typeahead suggestionsSuggest matching popular queries while someone types, using prepared prefix lists instead of rescanning every saved term.
- 56Design an API rate limiterApply one account’s burst and refill budget across API servers, and define what callers do when the shared check fails.
- 57Design Twitter searchFind posts matching a word query, then check their current text, deletion state and audience in the main post database before display.
- 58Design a web crawlerDiscover and revisit public pages without overwhelming sites, losing queued work or following links into private networks.
- 59Design a ranked news feed (Facebook)Build follower feeds from saved posts, limit the work needed for each page and recheck who may see each result.
- 60Design nearby places and friends (Yelp)Find public places inside a requested radius; for moving friends, also check the latest coordinates, report age and sharing permission.
- 61Design an Uber-style ride serviceFind nearby drivers quickly, then make one durable assignment despite retries, stale locations and racing acceptances.
- 62Design Ticketmaster-style seat bookingLet many buyers browse seat maps while preventing conflicting seat claims and retaining payment results needed after a timeout.
05
Bring it all together
Rehearse, challenge your design, and explain it aloud.
No chapters match. Try a different word or clear your filters.