ChannelPulse
System design
A system design round is a design review, not a vocabulary test. This track builds the method — requirements before boxes, arithmetic before opinions, one named bottleneck before any deep dive — and then the handful of mechanisms every real answer is assembled from.
Most candidates lose this round by drawing a correct diagram they cannot defend. The score comes from the trade-offs you name out loud, so that is what this track drills.
The method — requirements, arithmetic, storage, caching
The four things that decide the round before you get anywhere near a fan-out strategy: how the 45 minutes are actually scored, how to size a system in your head without lying, how to pick a datastore for a reason you can state, and how caching changes the numbers you just computed.
-
1
What the round actually measures
A system design interview is forty-five minutes of design review conducted on a system that does not exist yet. This is the time budget that survives contact with a real interviewer, and the four signals your score is actually assembled from. Free -
2
Back-of-the-envelope estimation
The eight minutes of arithmetic that make every later decision decidable — QPS from one anchor number, storage over five years, and the single question all of it exists to answer: does the hot set fit in memory? Free -
3
Picking a datastore, for a reason you can state
"SQL versus NoSQL" is the wrong axis and interviewers know it. The real decisions are your access pattern, your consistency requirement, and whether your storage engine is a B-tree or an LSM tree — and the last one explains most of what people mean when they say a database is "fast at writes". Free -
4
Caching, eviction, and stampedes
A cache is the cheapest way to hit a latency target and the easiest way to invent a new outage. This is where the caching patterns actually differ, why a stampede is arithmetic rather than bad luck, and the access pattern that separates LRU from LFU. Free
Mechanisms — replication, queues, limits, and placement
The four machines every distributed answer is assembled from, each derived rather than named. How copies of data disagree and what a quorum actually buys; why a queue is a decision about what to drop, not a way to go faster; what a rate limiter costs per request and where the counter lives; and how to move a key to a machine so that adding a machine doesn't move every other key.
-
1
Replication, quorums, and what "consistent" means to your interviewer
One copy of your data is a single point of failure; two copies are a disagreement waiting to happen. This derives what replication buys, what a quorum guarantees and — more importantly — what it does not, and how to answer "is this strongly consistent?" without reciting CAP. 24 min · app -
2
Queues, backpressure, and what you are willing to drop
A queue does not make a slow system fast; it changes what happens when the system is too slow. This derives the arithmetic of a growing queue, the difference between a buffer and a backlog, exactly-once as a fiction you replace with idempotency, and why every queue design is really a policy about dropping work. 25 min · app -
3
Rate limiting: four algorithms, one distributed problem
Every rate limiter answers the same question — may this request proceed? — and the four standard algorithms differ only in what they remember. This builds the token bucket and the sliding window from scratch, shows the burst the fixed window lets through, and then confronts the part that is actually hard: making the counter correct across many servers. 26 min · app -
4
Consistent hashing, and why `hash % N` breaks on the day you scale
Placing a key on a machine looks like a one-line problem until the machine count changes. This measures how much data `hash % N` moves when you add a node, builds the ring that fixes it, shows why the ring is lumpy without virtual nodes, and names what consistent hashing still does not solve. 24 min · app
Cases — three designs, worked end to end
The mechanisms assembled into full answers under interview conditions. A URL shortener that forces you to be precise about id generation and read scaling; a news feed that makes you choose who pays for the fan-out; and a typeahead that is really a question about how much precomputation you can afford. Each one is built in the order an interviewer expects to hear it, with the numbers written down.
-
1
Design a URL shortener
The classic warm-up, and the one candidates most often answer shallowly. This works it in interview order — requirements, numbers, id generation, storage, the read path, then the parts that decide the grade: expiry, custom aliases, analytics that don't slow the redirect, and abuse. 28 min · app -
2
Design a news feed
One question decides this design — does the poster pay to deliver, or does the reader pay to assemble? This works the cost model in numbers, shows why every real feed is a hybrid, implements the k-way merge the read path needs, and handles the celebrity problem, ranking, and pagination that does not skip posts. 28 min · app -
3
Design search typeahead
Suggestions must appear in under 100 ms while the user is still typing, which rules out ranking anything at read time. This derives the latency budget, builds a trie whose nodes cache their own answers, and then handles the parts that make it a real system — updating popularity from a stream, trimming memory, and personalisation. 26 min · app
Work through it with feedback
Reading the pattern is step one. The app runs you through it — editable code cells, the question bank, and a mock loop that grades your answer.
Open the curriculum in ChannelPulse