System design walkthroughs · AI/ML system design · paper labs · algorithm steppers · animated, interactive, interview-shaped

Architecture you can take apart with your hands.

Each entry is a single self-contained page that walks one system, one paper or one algorithm from first principles to working machinery. For systems — consumer products and the AI/ML infrastructure underneath them alike — that means requirements, envelope, high level, then one deep dive at a time, with the papers and production writeups the design is built on cited where each idea is introduced. For papers, it means the thesis, the algorithm, the hardware model, and local experiments you can rerun. For algorithms, it means the statement, the vocabulary it assumes, and then the code stepped one line at a time next to the data it is moving. Every mechanism that matters is animated or interactive.

walkthroughs
2
ai/ml designs
0
papers
1
problems
0
models
0
sections
—
deep dives
—
status
growing

AI/ML system design

The same treatment, pointed at the systems that serve and train models rather than at consumer products — plus the occasional teardown of two real implementations against each other. Each one is chosen because it has a genuinely hard core that the ordinary web-scale playbook gets wrong — and each is built against the papers and production writeups that define how the thing is actually done, cited inline and listed in full at the end of the page.

Papers

Systems papers get the same treatment as architectures: a concrete thesis, a visual model, code you can read, and local experiments where the machine is available.

Models

The same stepper, pointed at a released implementation rather than at an interview problem — the code a frontier model is actually served by, or the code that watermarks what it writes. The listing is the released file, vendored byte for byte; the tensors beside it were produced by running that file on the RTX 4090 in this machine and writing down everything it did, so the page replays real inference with no GPU and no network. Where something is too large to run whole, the page says exactly what was cut and measures the substitution rather than waving at it — and where nothing had to be cut, it says that too.

Algorithms

Interview problems read at the speed you would actually have to reason at. Each one opens as a written brief — statement, constraints, the vocabulary the statement assumes, and the approach in numbered moves — and then runs as a stepper where the code, the live values and a picture of the data advance one line at a time.

Nothing matches that. Clear the search or pick a different tag.

How every walkthrough is laid out

The numbering is the same across the series on purpose. Sections 00–03 are the interview opening you should be able to deliver from memory in ten minutes; the middle is where the design actually lives; the last third is the material that separates a good answer from a complete one.

00 – 03 · the opening
Frame, requirements, envelope, high level
Scope and the cuts, two or three numbers you will design against, an envelope you can drag, and the whole architecture on one board. Ten minutes, and it sets up everything after it.
04 – 13 · the deep dives
One hard problem at a time
The parts that are actually difficult, each with a replayable request trace, a payload panel, and a live model you can push until it breaks. This is where the interview is won.
14 – 21 · the closing
Data, APIs, failure, cost, follow-ups
Schemas, endpoints, the consistency boundary drawn explicitly, degraded modes you can switch on, what it costs, and the follow-up questions with answers short enough to say aloud.

What is interactive

Reading an architecture diagram teaches you the boxes. Moving the inputs teaches you why the boxes are there — which is the part an interviewer is actually probing.

sliders
Envelopes you can push
Change the users, the seats, the demand ratio, the shard count. Every derived number recomputes, and you can watch exactly which quantity crosses the line that forces a design decision.
trace players
Request paths, step by step
Press replay and walk a write through the system with the real payload at each boundary and a sentence on why the boundary exists at all.
simulations
Systems under load
A queue draining, a seat map selling out, a traffic curve collapsing past saturation. The numbers come from the model, so they move when you change the assumptions.
component inspector
Click any box
Every node on the high-level diagram opens its stack, its internals, its scale and the way it fails — because the interesting answer is rarely what a component does.
failure switches
Break it on purpose
Take a component out and read the blast radius, the user-visible symptom, the degraded mode, and the sentence you should say about it.
follow-ups
The questions you will get
A dozen per design, in the order interviewers ask them, with answers written to be spoken in two sentences rather than read.

Coming to the shelf

Same structure, same interaction vocabulary. Each one is chosen because it has a genuinely hard core rather than a long list of features.