In this chapter
We'll learn to read any architecture diagram like a map — the common shapes and arrows, where to start, how to follow a request, and the five questions to ask — then read BlueTicket's finished Sale Day diagram end to end.
The Problem in Real Life
John takes a photo of the whiteboard and puts it in the team's design document. Then he opens a different diagram — one from the payment company BlueTicket uses — full of boxes, cylinders, clouds and dashed lines. "Read this one to me," he says.
Anna stares at it. A week ago, it would have looked like abstract art. Now, slowly, she starts to recognise the shapes.
A diagram is a map. Find where you are, follow the roads, and ask what happens if one disappears.
John
Staring at Boxes vs. Reading a Map
Diagrams are everywhere
Design documents, onboarding, incidents and interviews all use architecture diagrams.
No single standard
Every team draws a little differently, but most use the same handful of shapes.
Reading is a method
Knowing where to start and which questions to ask turns any diagram into a story.
Reading an Architecture Diagram
The map analogy: a city map uses a few symbols everyone learns — roads, rivers, train lines, hospitals — and you read it by finding where you are and following a route. Architecture diagrams work the same way. There's no single official standard, but most diagrams use the same small set of shapes.
- Rectangles — programs and services: app servers, workers, services, the load balancer.
- Cylinders — databases and data stores: PostgreSQL, Redis, the queue's storage. If it stores data, it's usually a cylinder.
- People or device icons — users and clients: fans, organisers, browsers, phones.
- Clouds — the internet or a cloud provider: "the internet," or a box labelled with a cloud provider's name.
- Arrows — who talks to whom: an arrow usually points from the side that starts the request to the side that answers. Labels on arrows say how (HTTPS, SQL, a queue message). A solid arrow is usually a direct request; a dashed one often means "later" or "in the background."
- Dashed boundaries — groups and zones: a dashed box around several parts means they belong together: one network, one data centre, one company, "inside our system." Anything outside it — like the SMS provider — is someone else's.
| Shape | Usually means | Example |
|---|---|---|
| Rectangle | A program, server or service | App server, worker, load balancer |
| Cylinder | A database or data store | PostgreSQL, Redis |
| Person / device icon | A user or client | Fan, organiser, browser |
| Cloud | The internet or a cloud provider | "Internet", "Cloud provider" |
| Solid arrow | A direct request, from caller to callee | App server → database (SQL) |
| Dashed arrow | Background or later | App → queue → worker |
| Dashed box | A boundary or zone | "BlueTicket", "Zone A", "Third party" |
| Question | Why it matters |
|---|---|
| What does this box do? | Understand each part's job |
| Where does the data live? | Find the source of truth |
| What happens if this box disappears? | Find single points of failure |
| Where's the slow part? | Find what users wait for |
| What happens in the background? | Find asynchronous work and what can go missing |
BlueTicket's Sale Day architecture, read top to bottom
Fans (people icons)
start here — browsers and apps
Internet (cloud) → CDN
static files answered close to the fan
Load balancers ×2 (rectangles)
inside BlueTicket's boundary (dashed box)
App servers ×4
stateless, business logic
PostgreSQL main + standby (cylinders)
SQL
Redis main + replica (cylinders)
sessions, cache
Queue → workers → SMS provider
dashed: in the background, outside our boundary
How to read any diagram, in four steps: 1. Find the user — usually at the top or left. 2. Follow one request along the arrows, all the way to the data and back: "a fan buys a ticket — where does that go?" 3. Notice the boundaries: what's ours, what's a third party, what's in which zone. 4. Ask the five questions below.
The five questions to ask any diagram: What does this box do? Where does the data live? What happens if this box disappears? (the SPOF question from the last chapter). Where's the slow part? (like the SMS in chapter 3). What does the user wait for, and what happens in the background? These five questions are also what interviewers ask in system design interviews.
Anna reads the payment company's diagram: "The fan starts at the top. Their browser sends payment details over HTTPS to the payment company's API gateway — that's their front door. The gateway routes to a payment service, which talks to its database — a cylinder — and to the bank, outside their boundary. When the payment succeeds, a dashed arrow goes to a queue, and a worker sends us a message later — a webhook." She stops. "So the confirmation we get from them is asynchronous. If that message gets lost, we'd have charged a fan without knowing." John raises his eyebrows. "Remember you said that," he says. "You'll need it in Act 23."
Key Takeaway
Read an architecture diagram like a map: rectangles are programs and services, cylinders are data stores, clouds are the internet or a provider, arrows point from whoever starts a request, and dashed boxes mark boundaries. Find the user, follow one request to the data and back, notice what's inside and outside your system, then ask: what does it do, where's the data, what if it disappears, where's it slow, and what happens in the background?
Why This Matters
Architecture diagrams are how engineers explain systems to each other — in design documents, onboarding, incident reviews and interviews. Being able to read one in minutes, and ask the five questions, is how Anna will get up to speed on any new system, including the unfamiliar codebase waiting for her in Act 25. The System Design Fundamentals course turns these diagrams into full designs.
The Sale Day architecture is on the wall next to the countdown: 182 days to go. Before John signs it off, he wants to see Anna find every weak spot in the diagram of BlueTicket as it is today.