I Know What I Need, But I Don't Know How To Build It
Pick the thing you need. Then derive it: meaning, state, operations, rules, examples, representation, pseudocode — and only then the code, one rung at a time.
“I know I need a shopping cart. I have no idea how to implement a shopping cart.” The gap is not a missing tutorial; it is a missing method. Every stage below asks you to write before it shows you anything, because the code is the last step of a derivation, not the first thing to search for.
Which concept?
Grouped by exercise level; the level is how far the derivation goes, not how hard the code is.
How much help?
Every stage's content is shown right after your attempt box.
Rate Limiter — twelve stages
I know I need a rate limiter — no more than a hundred requests a minute per API key (illustrative). I have no idea how to implement a rate limiter.
Define the concept
In one sentence, without any code: what is it? Then answer for yourself — does it have identity, who owns it, how long does it exist, should it survive a reload or a login?
Rate Limiter = A gate that answers "may this key make one more request now?" so that no key makes more than N requests within one window.
- Does a rate limiter have identity? The limiter does not; its entries do. There is one entry per key — an API key, a user, an IP address — and the entry is identified by the key. Two keys with the same count are two entries and never interact.
- Who owns it? The service that is protecting itself. The client does not own its entry and cannot reset it; that is the point. The key is the client's identity as the service sees it, which is a security decision made elsewhere.
- How long does an entry exist? One window. An entry that has not been touched for a window is worthless and can be forgotten; the limiter is the rare concept whose state is meant to expire. Memory is bounded by the number of active keys, not by history.
- Should it survive reload? Usually no. A restart that forgets every count lets every key start fresh for one window — an acceptable loss for most services, and a reason the store can be a cache rather than a database. A limiter that guards a paid quota is a different concept and does need durability.
- Should it be shared across servers? Yes, as soon as there are two. A limit of N per server is a limit of N × servers per key, which is not the limit anyone wrote down. This is the V2 step, and it is where the counter moves into a central store.
The catalog is one derivation, not the only one (impl §60). A different set of examples yields different rules; a different first requirement yields a different V1; a map instead of an array is not wrong, only an answer to a different question. Compare your derivation with the reference for the differences, then decide which ones were rules and which were style.
Take it further
The flagship exercise: the cart typed by you, with the reference hidden until you ask.
Make It Smaller Until You Know How to Build It →The principle behind the ladder, and the primitive chain it produces.
The Implementation Loop →The loop the twelve stages follow, and why the code is last.