Using Diagrams Well in System Design Interviews

You run out of time. You draw every part you know before you explain any of them, and the clock runs down before the reasons get said. System design diagrams help only when each box comes with a spoken reason.

Picture a common setup. You get a 45-minute system design round, and the prompt is a URL shortener: a service that turns a long web address into a short code. The setup is made up, but the problem is real.

A first attempt often goes like this. You know the problem, so you start drawing at once: gateways, queues, three kinds of storage, a search index, an analytics pipeline. You will meet most of these later, each with a plain meaning. By minute 30 the board holds 19 boxes and 26 arrows.

Then the interviewer points at the queue and asks why it is there. The honest answer is that big designs usually have one. No requirement you collected needs it, and 15 minutes are left.

Each box was reasonable on its own. You never said what problem it solved, so the interviewer could not give you credit for it. This guide redraws the same URL shortener step by step, so you can watch one design grow for a reason.

System design diagrams in an interview are quick sketches of boxes and arrows that show the main parts of a system and how data moves between them. They support your explanation; they never replace it.

A box is one part of the system, such as a server, a database or a cache. A cache is fast, short-term storage that keeps popular answers close by, so you skip slower work. An arrow shows one thing moving from one part to another, such as a request or a saved record.

In a typical round you draw up to four kinds of picture, and none of them needs to be pretty.

• High-level diagram: the main parts and the arrows between them. You draw it once, early, and add to it as the talk goes on.
• Request flow: numbered steps that walk one request, such as a click on a short link, through the boxes you already drew.
• Deep-dive sketch: a small, separate drawing that zooms into one box, such as how short codes get created.
• Data sketch: a few tables or keys with their main fields, such as the short code, the long address and the owner.

Working architects use the same idea of zoom levels. The C4 model, which its site calls a developer-friendly approach to architecture diagrams, has four levels. They are system context, containers, components and code, each one zoomed in further.

In C4, a container is an application or a data store, such as a web app or a database. The container diagram shows how the work is split across them and how they talk. The C4 site notes that this diagram says very little about load balancers, clustering, replication or failover.

A load balancer spreads requests across several servers, and clustering means running several copies of a part together. Replication means keeping copies of data on more than one machine. Failover means switching to a spare when the main one dies. C4 puts those details in separate deployment diagrams, one per environment, such as production (the live system) or staging (a test copy).

That is a useful hint for interviews. Your first drawing should look like a container view: the apps and stores that do the work. The plumbing comes later, if it comes at all.

You should draw less because the interviewer is judging your reasoning, and reasoning lives in what you say. A box shows that a part exists. Only your words say why it is there, what it costs and what breaks without it.

Think of a family astrologer who visits a home to read a child's kundli, the birth chart. He sketches the chart in two or three minutes: a square, twelve houses, a few planet names in their places. Then he spends most of the visit talking.

Map the parts across. The chart is your diagram. Each house is a box. His reading of each house is your explanation of each part. The family pointing at a house and asking about it is the interviewer pointing at a box.

Where the picture breaks: the family mostly listens, while an interviewer challenges each claim and expects a number behind it. Your diagram must survive questions, not just be pointed at.

Martin Fowler, a well-known writer on software design, calls this way of working UML as sketch. UML, the Unified Modeling Language, is a standard set of diagram symbols. Fowler writes that the essence of sketching is selectivity: you draw the parts that matter and leave the rest out.

His sound-bite for it is "comprehensiveness is the enemy of comprehensibility". In plain words, a drawing that shows everything is a drawing nobody can read.

A rule of thumb we suggest, not a published standard: keep drawing to under a third of the round. In a 45-minute round that is about 15 minutes. The rest belongs to explaining.

Aim for roughly five to nine boxes in your first high-level diagram, covering the main request path from users to storage. This is our rule of thumb, not a law. It is enough to show a real design and small enough to explain in the time you have.

Try a second attempt at the same prompt with one new rule. No box goes on the board until you have said out loud which requirement it serves. So you start with questions instead of shapes.

Say you learn three things. Links never expire unless their owner deletes them. The service creates about 100 million new links a month. Each link is opened about 100 times on average, so reads far outnumber writes.

Next comes a back-of-the-envelope estimate: quick, rough maths done in your head. A 30-day month has about 2.6 million seconds. So 100 million links a month is about 39 writes a second; call it 40.

Reads are 100 times that, about 3,900 a second; call it 4,000. You write both numbers in a corner of the board, where you can point at them later.

Storage gets the same treatment. Say each link takes about 500 bytes with its details. Over five years that is 6 billion links and about 3 terabytes (3 TB). I'd say that number does not ask for a special storage system on day one.

Only now do you draw. Look at how few boxes there are.

The load balancer spreads incoming requests across several servers, so no single one gets overloaded. You add it so the link service can run on several servers: one can fail without taking the service down, and more can join as traffic grows. Say that before you draw the box.

Now go back through the first board and sort every box. The table shows one way to decide. None of the cut boxes was wrong. Each one simply arrived before the requirement that justified it.

A CDN, or content delivery network, is a set of servers spread around the world that answer requests close to the user. An API gateway is a single front door that checks logins and request limits for many services. A message queue holds messages so one part can hand work to another later.

All three are good tools. None of them was asked for yet.

Every box should say what it is and what job it does, and every arrow should say what moves along it, in one direction. Someone glancing at the board should follow the design without you explaining the shapes.

The C4 model's notation guidance says much the same. Every element should have a short description of its key responsibilities. Every line should show a one-way relationship and carry a label. It asks you to avoid single-word labels such as "Uses".

Here are the labelling habits worth practising:

• Name boxes by their job, and add the product only if it matters. Redis is a popular in-memory store, and "Link cache (Redis)" says more than "Redis" alone.
• Label arrows with a verb and the thing moving, like "save link" or "look up code", never just "calls".
• Use one arrow for each relationship. The reply travels back along the same arrow, so skip a second arrow returning.
• Put key numbers in a corner: writes per second, reads per second and storage over five years.

On a shared online whiteboard the rules stay the same, but typing labels is slow. Keep labels to two to four words, and put any longer detail in what you say, not on the board.

Number the arrows on the diagram you already have, then walk through one request, one step at a time. You show what happens over time without spending minutes on a second drawing.

The C4 model calls this kind of picture a dynamic diagram. It uses numbered interactions to show how parts work together at runtime for one feature or user story. The C4 site says to use them sparingly, for interesting or repeated patterns or for complicated interactions.

Say the interviewer asks what happens when someone opens a short link. Draw nothing new. Write small numbers beside the existing arrows and talk through each one. The picture below draws those steps as boxes; follow the two arrows out of the question box.

Here is roughly what you say at each step. Every step takes a sentence or two, and the last one adds a decision the picture alone could never show.

1. 1

   The click arrives

   The browser sends the short code to the load balancer. It forwards the request to a link service server that is passing its health checks, the regular are-you-alive tests.

2. 2

   Check the cache

   The link service looks up the code in the cache. If popular links get opened again and again, most clicks end here.

3. 3

   Fall back to the database

   On a cache miss, the service reads the long address from the database. It then saves the answer in the cache, so the next click for that code is fast.

4. 4

   Send the redirect

   The service replies with a redirect, an answer telling the browser to go to another address. Say which kind you pick, and why.

That last step shows talking beyond the boxes. A permanent redirect (status 301) may be remembered by the browser, so later clicks can skip your service. A temporary one (status 302) normally comes back each time, which helps if you count clicks.

The engineer section on redirects shows the caching rule behind that difference, and how to check what your own service sends.

Zoom in when the interviewer picks a deep dive, or when one box hides the hardest problem in the design. Draw a small, separate sketch of that one box beside the main diagram, and leave the main diagram as it is.

Say the interviewer asks how the service makes short codes so that two links never get the same one. On the main diagram this is hidden inside the single box called link service.

Start with a number before any shape. A code of 7 characters, each a small letter, a capital letter or a digit, has 62 choices per place. That gives 62 to the power 7, about 3.5 trillion codes, far more than the 6 billion links estimated.

Then pick a counter. A counter store hands each server a block of 1,000 fresh numbers at a time. The server turns each number into a short code by writing it in base 62, using those 62 symbols as digits. Look for the question box where a server runs out of numbers.

Base 62 works like ordinary counting, just with 62 digits instead of 10. With the digits 0 to 9 first, the number 125 is two sixty-twos plus one, so it becomes the code 21. Start the counter at 62 to the power 6 and every code has exactly 7 characters, until the space runs out.

Then say what this choice costs. Codes from one block come out in order, so anyone can guess the next link. If owners care about privacy, you could shuffle the numbers first, or use random codes and check each one is free.

There is a second cost. If a server crashes, the unused numbers in its block are simply never issued. As long as the counter store hands out each block once, that leaves gaps, not duplicates. Saying both costs takes 20 seconds and no new boxes.

Use a short loop for every box: say the requirement, draw the box, say why it is there, then say what breaks if it fails. You draw during one step and talk during the rest.

Follow the arrows from the top. The question box at the end sends you back round until every requirement has a part, then on to walking a request.

Here is how the loop sounds for the cache:

• Requirement: reads are about 100 times writes, so the same codes get looked up again and again.
• Box: a link cache beside the link service, holding popular codes in memory.
• Why: most clicks never touch the database, so the database mainly handles writes and cache misses.
• What breaks: if the cache goes down, every click hits the database, so the database must survive about 4,000 reads a second until the cache is back.

Avoid long silent stretches. If a box takes ten seconds to draw, say what you are drawing while you draw it. In an online round the interviewer cannot see your thinking, only hear it.

Also avoid the opposite habit: reading out names. "This is the load balancer, this is the server" describes a picture the interviewer can already see. Say what each part decides, protects or costs instead.

Each interview picture has a close match in the C4 model, and the match tells you what to leave out. The table pairs them, using the C4 site's own descriptions as of 19 October 2026.

The load balancer in our five-box diagram departs from C4's container view on purpose. In an interview, running several servers so one can fail makes it part of the story. In a team design document you would move it to the deployment diagram.

Turning a sketch into a diagram your team keeps

A sketch only has to survive 45 minutes with you standing next to it. A diagram in a design document must explain itself. The C4 notation guidance adds three rules that interview sketches usually skip.

• Give every diagram a title that names its type and scope, such as "Container diagram: URL shortener".
• Add a key, or legend, that explains the shapes, colours and line styles you used.
• Make every acronym understandable to all readers, or explain it in the key.

Run the numbers once before your interview, so you trust them when you say them. This script repeats every estimate and short-code number in this guide, using only Python's standard library.

SECONDS_PER_MONTH = 30 * 24 * 60 * 60
LINKS_PER_MONTH = 100_000_000
OPENS_PER_LINK = 100
BYTES_PER_LINK = 500

writes = LINKS_PER_MONTH / SECONDS_PER_MONTH
reads = writes * OPENS_PER_LINK
links_5y = LINKS_PER_MONTH * 12 * 5
storage = links_5y * BYTES_PER_LINK

print(f"seconds in 30 days: {SECONDS_PER_MONTH:,}")
print(f"writes per second: {writes:.1f}")
print(f"reads per second: {reads:,.0f}")
print(f"links in 5 years: {links_5y:,}")
print(f"storage: {storage / 1e12:.1f} TB = {storage / 2**40:.2f} TiB")

ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"


def base62(n):
    code = ""
    while True:
        n, digit = divmod(n, 62)
        code = ALPHABET[digit] + code
        if n == 0:
            return code


print(f"7-character codes: {62**7:,}")
print("125 becomes:", base62(125))
print("first 7-character code:", base62(62**6))
print("last 7-character code:", base62(62**7 - 1))

Save it as shortener_check.py and run python3 shortener_check.py. On Python 3.13 it printed exactly this:

seconds in 30 days: 2,592,000
writes per second: 38.6
reads per second: 3,858
links in 5 years: 6,000,000,000
storage: 3.0 TB = 2.73 TiB
7-character codes: 3,521,614,606,208
125 becomes: 21
first 7-character code: 1000000
last 7-character code: ZZZZZZZ

Check the units. 3.0 TB means 3 trillion bytes. Tools that count in powers of two show the same size as 2.73 TiB (tebibytes), because one tebibyte is 2 to the power 40 bytes.

Notice 38.6 writes a second. Saying "about 40" out loud is fine; the script shows how much you rounded. The first and last 7-character codes, 1000000 and ZZZZZZZ, show why starting the counter at 62 to the power 6 keeps every code the same length.

What we tested about the block counter

We also ran the block-counter design in Python 3.13: four threads, each a server taking blocks of 1,000 from one locked counter. Here is what it showed.

• No duplicates: in each of 20 rounds, 4 servers made 25,000 codes each, and the 100,000 codes had no repeats.
• Gaps after a crash: a server that used 10 numbers and then restarted skipped the other 990 of its block.
• Guessable order: three codes in a row from one server came out as 1000021, 1000022 and 1000023.
• Room to spare: 6 billion links use 0.17% of the 3.46 trillion 7-character codes that start at 62 to the power 6.

The no-duplicates result depends on the counter store handing out each block exactly once. In our test a lock did that. Without the lock, and with a short pause between reading and writing the counter, both servers got the same block in 100 of 100 rounds.

So in a real system, reading and writing the counter must be one atomic step in the store: one indivisible operation no other server can interrupt. Otherwise two servers can read the same value and hand out the same codes.

Send a 302 if you must see every click, and a 301 if you would rather let browsers skip your service on repeat clicks. The difference is caching, and you should say which one you want. Caching headers can change it either way, as the rest of this section shows.

MDN, the Mozilla web docs, describes 301 Moved Permanently as a permanent move to the address in the Location header. It describes 302 Found as a temporary move. In both cases the browser then loads the new address.

Caching is where they part. MDN's glossary lists 301 among the status codes that are cacheable by default; 302 is not on that list. RFC 9111, the HTTP caching standard, still lets a cache store a 302 that carries an explicit lifetime, such as a Cache-Control max-age or an Expires header.

The same standard lets a cache guess how long to keep a response with no explicit lifetime. It may guess only for status codes that are cacheable by default, such as 301, or for responses marked cacheable, for example with Cache-Control: public. It suggests a typical cap, 10% of the time since the response last changed, but gives no exact algorithm. So how long a browser keeps a 301 with no caching headers is up to that browser, as of 19 October 2026.

To see what a short link sends, ask only for the headers with curl -sI followed by the short link. The first line gives the status, and the Location line gives the target. Against a local test server, ours printed these lines:

HTTP/1.0 301 Moved Permanently
Location: https://example.com/a-very-long-address

A real server may print HTTP/1.1 or HTTP/2 instead of HTTP/1.0, and add more headers. Look for a Cache-Control or Expires line too: it can tell browsers how long they may keep the redirect, or not to keep it. RFC 9111 says a response sent with Cache-Control: no-store must not be stored, even a 301. So for click counting, the headers matter as much as the code.

The -I option makes curl send a HEAD request, which asks for the headers only, and some services answer HEAD differently. If a real link gives an odd answer, run curl -s -o /dev/null -D - followed by the link. That sends a normal GET, the request a browser makes when you click, and prints only the headers.

Collect requirements and numbers first, draw the smallest diagram that serves them, walk one request through it, then zoom into one part and discuss trade-offs and failures. Here is the order as steps.

1. 1

   Ask, then write numbers

   Spend the first few minutes on requirements and a rough estimate. Write the key numbers in a corner of the board, where you can point at them later.

2. 2

   Draw the main path

   Draw five to nine boxes from users to storage. Give each one its job, and tie each to a requirement you said out loud.

3. 3

   Walk one request

   Number the arrows for the most common action, like opening a short link. Say each step in a sentence or two.

4. 4

   Grow only on demand

   Add a queue, a database copy or a second cache only when a number or a question asks for it. Say which one.

5. 5

   Zoom into one box

   For the deep dive, draw a small separate sketch beside the main diagram. Explain its trade-offs in detail.

6. 6

   Close with failures

   Point at each box and say what happens if it stops working. This shows which parts need a backup copy or a fallback.

Followed in order, the same prompt plays out differently. The main diagram is done by minute 14, with the same five boxes. A sixth, a click counter fed by a queue, arrives only after the interviewer asks for daily click reports.

The rest of the round is talking: the redirect choice, the short codes and what fails first. The timings in this scenario are made up, but the order is the point.