Read a Software Architecture Diagram as a PM

A software architecture diagram shows how responsibilities are distributed across a system and how its parts communicate. Reading one starts with its scope and legend, then follows a specific user action through the relevant components. The useful questions concern what each part does, what data it holds and what happens when a dependency is slow or unavailable.

A checkout provides a concrete example. The screen where a customer clicks “Pay” may rely on order processing, stored data and an external payment provider. A change that looks small on that screen can affect several of those responsibilities. The diagram helps identify where the work belongs and which assumptions need checking before a delivery date is agreed.

Start with the question the diagram answers

Architecture diagrams operate at different levels. A context view places a product alongside its users and external systems. A more detailed view shows applications and data stores within the product. A deployment view shows where software runs, including infrastructure and network boundaries. Mixing these levels without explanation can make a diagram harder to interpret.

The C4 model distinguishes these views explicitly. Its container diagram uses “container” to mean an application or data store, which does not necessarily mean a Docker container. The example below is a simplified view of responsibilities and communication. It is not a complete C4 diagram or a production infrastructure plan, and it does not prescribe a particular technology.

A checkout diagram, with its boundaries explained

Mercato is a hypothetical commerce platform. In this example, a web frontend displays the checkout, an orders backend validates the request and coordinates payment, and a database stores the order and its payment state. The payment provider sits outside Mercato’s boundary because it is a separate system operated by another organization. The frontend runs in the customer’s browser, even though its code belongs to Mercato.

The browser calls the orders backend. The backend stores the order in a database and requests payment from an external provider. A later provider notification updates the order status through the backend.

Open the full-size diagram.

The solid arrows show requests between parts of the system; the dashed arrow shows a later notification from the payment provider. The numbers guide the walkthrough below. Responses and several production concerns are omitted, including identity checks, inventory and the payment provider’s browser-side collection of payment details. The diagram does not suggest that raw card data should pass through the orders backend.

A box represents a responsibility at the chosen level of detail. Several responsibilities can be implemented within one application, and one application may run across multiple instances. The number of boxes therefore does not establish whether this product uses microservices, how many servers it has or how much traffic it can handle.

Follow one order through the system

The customer submits the checkout through the frontend. The backend validates the request, checks the information required for the order and records an initial state. In this example, the server recalculates the amount rather than trusting a total supplied by the browser. This is where a proposed promotion would need to interact with pricing and eligibility rules.

The backend then requests payment from the provider, using a reference that allows the payment to be associated with the order. Depending on the payment method, the result may arrive immediately or require further customer action and later processing. The diagram separates requesting a payment from learning its final outcome because the product must handle the time between them.

For this example, a provider notification reaches the backend, which verifies it and updates the stored payment state. The customer’s view can then reflect the authoritative state held by the backend. The drawing omits that return path for readability; it does not mean the frontend can never request another status update.

A notification may be retried or arrive after another event. Processing therefore needs to avoid applying the same business action repeatedly and account for the order of state changes. Stripe documents these delivery behaviours for its webhooks. The product consequence is concrete: receiving a duplicate notification must not generate a second fulfilment instruction for the same order.

Read the arrows as dependencies

A request creates a dependency on the receiving part of the system. If the payment provider is slow, checkout may have to wait or show a pending state. If the database is unavailable, the backend may be unable to record an order safely. The diagram identifies where to investigate, but it does not reveal the actual timeout, retry policy or recovery behaviour. Those details need an explanation from the team.

A network timeout can leave the caller uncertain about the outcome. The provider might have accepted a payment even though the backend did not receive the response. Showing “payment failed” and immediately creating a fresh payment attempt could then produce an incorrect customer experience. The product needs a way to resolve uncertain states and guide the customer while the team checks the provider’s records.

A later notification reduces the need to wait for every result within the initial request, but it introduces a different dependency: the event still has to arrive and be processed. A delayed notification can leave a paid order marked as pending. Support needs enough information to distinguish that situation from an unpaid order before advising a customer to pay again.

Use the drawing to assess a proposed change

A delivery discount would affect what the frontend displays, how the backend calculates eligibility and what amount is sent to the payment provider. If the order must preserve the conditions accepted at checkout, the stored data may also need to capture those conditions. The diagram gives the team a shared place to trace that change; it does not establish the implementation effort on its own.

The same drawing can support a discussion about a payment-provider outage. Engineering might describe a pending-order path, a disabled payment method or a recovery process. Product can then decide what the customer sees and what support should communicate, within the technical and contractual constraints. A second provider is another architectural option, but adding one introduces integration and operational work that the drawing does not quantify.

Which component owns the authoritative order and payment states, and who can change them?
Which calls must finish before the customer can continue, and which results may arrive later?
What happens if a request times out after the receiving system has already acted?
How are duplicate notifications and conflicting updates handled?
Which parts change for this feature, and can their versions remain compatible during rollout?

What this diagram cannot establish

A high-level diagram does not prove that the checkout is secure, resilient or able to support a sales campaign. It leaves out access controls, deployment topology and measured capacity. It also cannot confirm how the system behaves during an incident without evidence from its running components. Those discussions may require a more detailed view, performance measurements or a trace of a real request.

Before using any diagram to plan work, check its date, owner and whether it describes the current system or a proposed design. An outdated connection can lead the team to overlook a dependency that now exists. For the concepts behind the boxes, read the software architecture guide. For changing versions while preserving customer access, see deployment vs. release.

The book Software Architecture for Product Managers develops the relationship between architecture and product decisions. The guide to APIs provides more detail on the requests and responses that connect the parts of a system.