How to draw a system-design diagram for an interview
Build a URL shortener diagram one decision at a time, then revise it when links need to expire.
Blog
Thoughts on system design, clearer diagrams, and the work behind Lycana.
Blog
Thoughts on system design, clearer diagrams, and the work behind Lycana.
A system diagram should be easy to revise
A diagram is useful when you can change your mind without redrawing everything.
Read articleRecent articles
Architecture diagram vs system-design diagram: which view do you need?
The names overlap. Choose what to draw by the decision your reader needs to make, then label the relationships that matter to that decision.
How to make an architecture diagram useful in a design review
Follow a checkout dependency decision from an ambiguous sketch to a reviewable view that shows the promise, failure path, and alternative.
Keep architecture diagrams useful as the system changes
Follow a service migration through three diagram revisions, and decide when an old view still helps or sends readers down the wrong path.
Voice vs typing for technical work: what the evidence actually says
A phone transcription study found a speed advantage for speech. A design change still has thinking, inspection, and correction time to account for.
The dead pixel trap: what a diagram export leaves behind
An approved PNG can show what a team agreed to draw. When a later change arrives, the team also needs the editable source, the decision behind it, and a way to tell which version was approved.
C4, UML, or boxes and arrows: choosing a notation
A shipping-service decision shows when an informal sketch is enough, when C4 clarifies boundaries, and when a UML sequence diagram earns its precision.
What to check before finishing a system-design interview diagram
Review a photo upload diagram for a premature success response, a missing failure state, and a private photo path that is not private.
One system, four architecture views
Follow one fictional appointment booking through context, runtime, module, and deployment views, then see how one design change alters each view.
Technical-debt statistics: what the numbers actually measure
Three often-cited studies measure different things. Read their questions and denominators before using a technical-debt statistic to plan engineering work.
What should survive after a whiteboard session?
Use a fictional preview-generation design session to decide when to keep a photo, when to write down the decision, and what can be erased.
Why two engineers can read the same diagram differently
A vague arrow can support two sensible stories. Follow one report-generation diagram through both readings and a revision that settles the question.
What an arrow leaves out: documenting an interface's contract
Turn a ticket reservation arrow into a clear agreement about requests, successful holds, timeouts, and who owns the seat state.
How an architecture decision becomes technical debt
A shared customer schema is a sensible shortcut until teams need separate releases and tighter access. Follow the costs that appear, and decide when to change it.
Why some late changes become expensive
Follow a store-scoped order number from an easy early revision to a deployed identifier migration with old records, integrations, and rollback to protect.
A queue does not finish the design
Follow one document job through a worker crash, a repeat delivery, and a failed-job queue to see which decisions the diagram must show.
What makes an architecture diagram editable?
Change one request path in an order system and see why component identity and labeled relationships matter more than movable boxes.
From description to diagram
A short way to turn a system explanation into something you can inspect together.