Use case

Preparing for system design interviews.

The diagram is the easy part. Interviews are decided by the tradeoffs you can defend when the interviewer pushes.

$curl -fsSL https://lucidtrain.com/install.sh | sh

URL shortener architecture. 10 components across 4 tiers. — URL shortener architecture. Produced by the app's layout engine from a semantic graph, not placed by hand.

What interviews actually test

Not whether you can draw a load balancer. Whether you can justify a choice, name what it costs, and change your mind when given new constraints. Candidates who have memorised diagrams fall over on the first follow-up because a memorised diagram carries no reasoning, and the follow-ups are the interview.

Reference designs with the arguments

There are 24 worked architectures covering the systems that come up most, and each one carries three to five design decisions written out with what they cost: why counter ranges beat hashing for a URL shortener, why fan-out on write breaks for high-follower accounts, why payment systems need idempotency keys. Reading the argument is the part that transfers; the boxes are not.

Practise redrawing quickly

Being able to produce the shape fast, and restructure it when a constraint changes, is a real skill and it improves with repetition. Because layout is computed, adding a cache or splitting a service costs one edit rather than a rearrangement, so a practice session covers more ground.

Be honest about the room

Most interviews happen on the interviewer's whiteboard tool, so this is preparation rather than something you will use during the interview. Anyone suggesting otherwise is selling you something.

A practice session

shell

# Design a system for 10 million daily active users posting short messages.
# Then: now make it work with a 50ms p99 read latency budget.

FAQ

Questions

Which designs should I study first?

URL shortener, chat, and a news feed. They cover read-heavy caching, stateful connections and the fan-out problem, which between them underpin most of the follow-up questions.

Is memorising reference architectures useful?

Memorising the diagrams, no. Memorising the arguments, yes, because the arguments generalise to systems you have not seen and the boxes do not.

Can I use this in the interview?

Almost certainly not. Interviews run on the interviewer's tool. Treat this as practice.

Technical Design Documents
The diagram in a design doc usually gets drawn last, badly, because everyone is tired of the document by then.
Migration Planning
Migrations fail on the intermediate states, which is exactly the part nobody draws.
Offline and Air-Gapped Teams
Every other tool in this category is a web application. If your code cannot go to a browser, that rules all of them out.
Keeping Diagrams in Sync with Code
Every architecture diagram is accurate on the day it is drawn. The question is what happens in month four.

Last updated 19 August 2026