How to read a system architecture diagram

There is a moment this entire curriculum has been moving toward.

An engineer stands at a whiteboard, draws several boxes, connects them with arrows, and the room begins arguing about what should happen inside each box.

Phase 4 is about being able to participate in that conversation.

It is possible because you already know many of the things represented by the boxes: the frontend, the backend, the database, the cache, object storage, third-party services, the load balancer, and cloud infrastructure.

Modules 4 through 8 introduced the individual pieces. Module 9 will teach you how to see them as one connected system.

The first skill is learning how to read the drawing.

What is system architecture?

A system’s architectureConcept · lights on your mapsystem architectureA system’s high-level structure: the major parts it contains, the responsibilities assigned to those parts, and the ways they interact. Not the detailed source code but the higher-level organization above it. is its high-level structure: the major parts it contains, the responsibilities assigned to those parts, and the ways they interact.

Imagine a coffee-ordering product.

Its architecture might include:

• A mobile frontend used by customers
• A backend that applies business logic
• A database that preserves orders and accounts
• A cache that provides frequently requested information quickly
• Object storage that holds menu photographs
• A payment provider that processes charges
• A messaging provider that sends confirmations
• Cloud infrastructure on which the company’s software runs

Architecture is not the detailed source code inside each part but the higher-level organization of the system.

A useful starting model is: architecture describes which major pieces exist, what each piece is responsible for, and how the pieces work together.

This is the “shape” of the system, but the shape includes responsibilities and relationships, not merely the number of boxes.

What is an architecture diagram?

An architecture diagramConcept · lights on your maparchitecture diagramA visual representation of a system’s architecture: boxes, arrows, labels, and boundaries at a chosen level of detail. Not a complete reproduction of reality: a simplified view created for a purpose. Ask what it is trying to explain. is a visual representation of a system’s architecture.

It commonly uses boxes, arrows, labels, and boundaries to show the system at a particular level of detail.

You have already encountered simpler versions of this idea.

In Module 1, you saw that a technical diagram might represent a payment journey as: customer app → payment system → bank.

You also learned that someone investigating a failure might need to zoom in: checkout page → payment API → fraud check → card network → bank.

Both diagrams can be correct, answering different questions and showing different levels of detail.

Architecture diagrams work the same way.

One diagram might show an entire company using five boxes, while another might open one of those boxes and reveal twenty smaller components inside it.

A diagram is therefore not a complete reproduction of reality but a simplified view created for a purpose.

Before reading one, ask: what is this diagram trying to explain?

What do the boxes represent?

A box usually represents a componentConcept · lights on your mapcomponentOne part of a larger system with a particular responsibility: a frontend, a database, a cache, an external provider. A service is one kind of component.: one part of a larger system with a particular responsibility.

Depending on the diagram, a box might represent:

• A frontend
• A backend
• A service
• A database
• A cache
• An object-storage system
• A third-party provider
• A server or group of servers
• An entire external system

The meaning comes from the box’s label and from the level of detail being shown.

Consider a box labeled Payment system.

From the perspective of the entire coffee product, that payment system is one component.

If you zoom into it, the payment system may become a larger system containing its own components: payment form → payment service → fraud check → payment provider → bank.

This is the abstraction principle from Module 1 appearing again. Each box temporarily hides internal detail so that the reader can focus on the relationships that matter for the current conversation.

What is a service?

Some components are called servicesConcept · lights on your mapserviceA kind of component that provides a capability to other parts of a system through a defined interface, often running as its own deployed application. Every service is a component; not every component is a service..

A service is a software component that provides a particular capability to other parts of a system through a defined interface, and it often runs as a separate process or deployed application, communicating with other components over a network.

Examples might include:

• An order service that creates and updates orders
• A payment service that coordinates payments
• An account service that manages customer accounts
• A notification service that arranges emails or text messages

However, not every box on an architecture diagram is a service.

A database, user device, cache, external company, or entire cloud environment may also appear as a box, so the word component remains the broader term, and a service is one possible kind of component.

What do the arrows represent?

An arrow shows that some kind of relationship or interaction exists between two parts of the system.

Depending on the diagram, an arrow might represent:

• A request being sent
• A response being returned
• Data being read or written
• An event or message being delivered
• A network connection
• One component depending on another

There is no single arrow grammar shared by every architecture diagram.

Some diagrams use an arrow to show the direction in which a request travels, while others use it to show the direction in which data moves. One arrow may represent both a request and the response that eventually returns.

Good diagrams often label their arrows:

When the meaning is unclear, look for a legend or ask what the arrows represent.

The safest rule is not “every arrow means data flow.”

It is: every arrow represents a relationship. Use its direction, label, and surrounding context to determine what kind.

Tracing a request through the diagram

Return to the coffee-ordering product.

A simplified architecture might look like this:

Suppose the customer taps Pay.

You can trace the interaction one step at a time.

The customer gives the mobile frontend information about the order, the frontend sends a request to the backend, and the backend validates the request, applies the product’s business logic, and sends payment information to the payment provider.

If the payment is approved, the backend saves the order in the database and asks the messaging provider to send a confirmation, then returns a result to the frontend, and the frontend displays the confirmation to the customer.

This is the same request-tracing skill you developed earlier in the curriculum. The architecture diagram places that journey onto a map.

When someone asks, “can you trace the data flow?” they are usually asking you to follow information through the system and explain:

• Where it begins
• Which components receive it
• What each component does with it
• Where it is stored
• What is sent next
• What eventually returns to the user

The phrase data flowConcept · lights on your mapdata flowThe path information takes as it moves through and changes within a system. “Trace the data flow” = follow information from where it begins, through the components that receive, transform, and store it, to what returns to the user. refers to the path information takes as it moves through and changes within a system.

What is a dependency?

A dependencyConcept · lights on your mapdependencyRe-encounter (Modules 3, 6, and now architecture): something a component relies on to perform a responsibility. On a diagram, often an arrow from the component using a capability to the one providing it; also the path along which failure can propagate. is something a component relies on in order to perform a responsibility.

Suppose the backend cannot complete checkout unless the payment provider approves the charge.

For that operation, the backend depends on the payment provider.

Suppose the backend needs the database to retrieve the customer’s rewards balance.

The backend depends on the database for that information.

Architectural dependencies are the connections between components that allow the product to function.

A diagram often represents a dependency with an arrow from the component using a capability to the component providing it: Backend → Payment provider.

This can be read as: the backend calls the payment provider, so the backend depends on it.

However, arrow conventions vary. You should confirm what the arrows mean before deciding which direction the dependency runs.

How failures move through a system

Dependencies matter because one component’s failure can affect other components. Imagine that the coffee company’s frontend, backend, and database are all operating normally, but the payment provider becomes unavailable.

Customers may still be able to browse the menu and view their accounts, but they may be unable to complete a purchase because checkout depends on the unavailable provider.

The original failure occurred outside the coffee company’s systems, but it became part of the coffee company’s customer experience.

This does not mean every dependency failure automatically causes the entire product to fail.

A system may:

• Retry the request
• Use a backup provider
• Save the order as pending
• Allow unaffected features to continue working
• Display a clear message asking the customer to try again later

Architecture determines how successful work travels through a system and how failures can spread or be contained.

A useful principle is: failure can propagate from a dependency to the components that rely on it.

Why engineers study the arrows

The boxes tell you what the system contains.

The arrows tell you how tightly those pieces are connected.

A component with many other components relying on it deserves attention because if it becomes unavailable, the effects may reach several parts of the product.

However, counting arrows is only a starting clue.

Engineers must also ask:

• How important is the capability?
• Is there another component that can take over?
• Can the product continue in a reduced form?
• Is the information available somewhere else?
• Does the failure affect every user or only one feature?
• How quickly can the component recover?

Two boxes may have the same number of incoming arrows but create very different levels of risk, and the diagram helps engineers discover which questions to ask but does not answer every question by itself.

A repeatable way to read an architecture diagram

When you encounter a new architecture diagram, read it in this order.

First, identify the system’s purpose and the level of detail being shown, and second, locate the user or the event that begins the interaction.

Third, read the labels on the boxes and describe the responsibility of each component, and fourth, determine what the arrows mean by looking for labels, direction, and a legend.

Fifth, trace one request or piece of data through the system from beginning to end.

Sixth, identify where important state is stored and which component is the source of truth, and finally, identify the dependencies and ask what would happen if one of them became unavailable.

You do not need to understand every internal detail inside every box. Begin with the overall shape, then zoom into the parts relevant to the conversation.

Why architecture creates arguments

Every box represents a decision.

Which component should own a responsibility?

Which information should cross the boundary?

Should two capabilities live together or separately?

Should one team operate the component or another?

What happens if the component becomes slow or unavailable?

How independently should it be changed, deployed, or scaled?

These questions rarely have one universally correct answer because a design that works well for one product, team, or scale may be a poor choice for another.

That is why architecture discussions can become debates. The participants are doing more than drawing boxes. They are deciding how responsibilities, data, ownership, and failure will be distributed across the system.

The mental model to remember

System architecture is the high-level organization of a system: its major components, their responsibilities, and their interactions.

An architecture diagram is a simplified visual representation of that organization.

A box usually represents a component. A service is a type of software component that provides a capability to other parts of the system.

An arrow represents a relationship or interaction. Its exact meaning depends on the diagram.

Data flow is the path information follows through the system.

A dependency is something a component relies on to perform its responsibility.

When a dependency fails, the components relying on it may also fail or operate in a reduced form. Architecture influences how far that failure can spread.

When reading a diagram, remember:

• Boxes have responsibilities.
• Arrows show relationships.
• Trace the information.
• Find the dependencies.
• Ask what happens when something fails.

You should now be able to approach a basic architecture diagram, identify its major components, trace one interaction through it, and explain where dependencies create risk.