backplane
Start learning
Back to the map

Module 01 · Core concepts · Lesson 2 of 9

Reading a system diagram

Boxes, arrows, cylinders and dashed lines carry precise meanings. Learn the notation this track uses so every later diagram reads at a glance, and so your own whiteboard says what you mean.

IntroMust-knowJunior 8 min Updated Nov 2026

Why it matters

An architecture diagram is a shared language between you and the interviewer. A box that could mean a server or a service, an arrow that might be a request or a data copy, and a database with no indication of whether it is one machine or twenty will cost you minutes of clarification and leave the grader unsure what you meant. Fluency in the notation is cheap to acquire and pays on every whiteboard for the rest of your career.

The idea

Every diagram in this track uses the same five elements. Read them the same way each time.

Servicebox = processA box is a process or a logical service. Several replicas are still one box unless the count matters.StoreA cylinder is a datastore: database, cache, object store. Its label says which.requestA solid arrow is a synchronous request; the caller waits. The label says what is asked.eventA dashed arrow is asynchronous: a message, an event, a background copy. Nobody waits.boundaryA dashed box groups components: a region, a network boundary, a team's ownership.
The notation used throughout the track.

Colour is a highlight, not a legend. The accent colour marks the component the lesson is about; the red tone marks a failure or a hot path; grey is context.

Reading a request path

Read a diagram the way a request travels: start at the client and follow solid arrows. Each hop you cross is latency and a place that can fail. When you reach a cylinder, ask two questions: is it one machine or many, and is it the source of truth or a copy?

Client1API2 readCache3 missPrimarytruthcopyReplica
Read left to right along the solid arrows: three synchronous hops, one asynchronous side effect.

Drawing one under time pressure

  1. 1

    Clients on the left, storage on the right

    Requests flow left to right. Put asynchronous work below the main path.
  2. 2

    Label every arrow with a verb

    "read profile", "publish event", "replicate". An unlabelled arrow is a question you will be asked.
  3. 3

    Mark counts only where they matter

    "x3" on the API box when you are about to discuss statelessness; "1 primary, 2 replicas" when you are about to discuss failover.
  4. 4

    Draw the failure before you are asked

    Cross out one box and say what happens. It is the fastest way to show seniority.

Trade-offs

A diagram is a model, and models leave things out on purpose. Too much detail (every microservice, every port) hides the request path; too little (one box labelled "backend") hides the decisions. Aim for the level where each box is a decision you could defend.

In an interview

Narrate as you draw. "Client hits the load balancer, which fans out to stateless API servers. Reads check the cache first, then the primary. Writes go to the primary and replicate asynchronously to two replicas, so reads from replicas can be a few hundred milliseconds stale." Every clause there is a design decision stated as a fact, which is exactly what the grader is listening for.

Check yourself

On a diagram, a dashed arrow runs from the API box to a box labelled 'Email worker'. What does it tell you?

Reading a system diagram · Backplane