A useful architecture diagram helps someone make a decision. Before choosing queues, databases, or services, decide which system you are designing and which promises it makes to the people around it.
This lesson shows how to draw a system context diagram for Fieldnote, a fictional stationery shop. You will identify the people and external systems involved in a purchase, draw an ownership boundary, and turn a vague requirement into a testable promise.
It opens the Online Store Architecture: From Boundaries to Reliable Orders learning route. You need no earlier lesson; basic experience using a web application is enough.
Start with one purchase
A shopper buys two A5 notebooks. They expect a clear answer about whether the order was accepted. Operations staff need a reliable list of paid orders to pack. The product team needs to understand which failures it can fix directly and which require another company's cooperation.
Fieldnote's first promise is precise: an accepted order has a confirmed successful payment, a saved order record, and allocated stock. An acceptance does not mean the parcel has shipped. A receipt email can arrive later.
This promise immediately separates essential work from follow-up work. If email is unavailable, checkout may still succeed. If payment is unresolved, the page must not announce that the order is accepted.
The quantities and prices used later are teaching inputs, not estimates of real demand or production capacity. We are designing a small shop with one product team, not assuming millions of requests or a global marketplace.
Draw the boundary around responsibility
Put one box in the center: Fieldnote Store — sells stationery and manages orders. Around it, place four participants:
| Participant | Relationship with Fieldnote |
|---|---|
| Shopper | Browses products, submits checkout, checks order status |
| Operations staff | Reviews payment exceptions and packs accepted orders |
| Payment provider | Processes payment requests and reports their outcomes |
| Email gateway | Accepts receipt-delivery requests |
Use directed, labeled relationships. “Fieldnote requests payment” and “Payment provider reports outcome” tell a reader more than an unlabeled line marked “integration.” The arrows show interaction, not a timeline; the sequence comes in lesson three.
This is the level of detail recommended by the C4 system context guidance: people, the system in scope, and neighboring software systems. Internal modules and database tables belong in a closer view.
The shopper is outside the software boundary even though they are central to the business. The payment provider is outside because Fieldnote's team does not own its implementation or availability. Operations staff are also outside: they use Fieldnote to do their work.
The browser application, backend, worker, and database are inside Fieldnote's ownership boundary. Leave them collapsed into the central box for now. A context diagram should make the scope readable before it explains the implementation.
Live model · Architecture view
Identify the store and its neighbors
The outer Fieldnote boundary encloses the software the product team owns. The shopper and operations staff interact with it; payment and email providers remain external. An unresolved payment prevents acceptance, while a delayed email does not. Start with these outer relationships before examining the modules.
Explore scenarios in this model
- Architecture view
- Checkout: preparation, payment and acceptance
- Accepted order: durable packing and receipt work
- Payment timeout: same identity, authoritative recovery
These links open the same public model in a selected view. They do not change its source.
Open this viewer on its own ↗ if the frame is unavailable. The explanation remains readable without the viewer.
Exploration is local to your viewer. Reload or Reset view returns to the source layout.
Separate ownership from trust
An ownership boundary answers “Who changes and operates this software?” A trust boundary asks “Which input must we verify?” They are related, but they are not interchangeable.
Fieldnote owns its storefront code, but a shopper can modify requests sent from their device. The backend must calculate the amount from trusted product and cart data. A submitted total of one cent is not evidence that two notebooks cost one cent.
Similarly, a message that claims to come from the payment provider is not automatically authoritative. A production integration needs the provider's documented verification and reconciliation mechanisms. The context diagram identifies that dependency; it does not prove the integration is secure.
Keep raw payment details out of this teaching example. Later contracts use a provider-issued payment-method reference. That is a scope choice, not a claim that drawing a provider outside the boundary satisfies payment compliance requirements.
Write down what the diagram excludes
Fieldnote uses staff to pack orders from an internal task list. There is no warehouse API hiding behind “fulfillment.” Carrier booking, returns, fraud review, tax calculation, and multiple warehouses are outside this route.
Excluding them keeps the first diagram useful. It also exposes the questions that would change the architecture. If a warehouse partner must reserve goods before a purchase can be accepted, it becomes an external participant on the acceptance path. If staff simply print a packing list later, it does not.
The trade-off is deliberate: a small view supports a clear conversation, while a wider view reveals more dependencies. Expand the boundary when a concrete decision requires it. Adding every possible actor in advance makes the current promise harder to see.
Try it in Unograph
In an architecture diagram, add Fieldnote and the four participants above. Label each relationship with a verb and an object. Add a note with the acceptance promise. Then ask a teammate to point to the dependency that prevents acceptance when its outcome is unknown.
Your result is useful when they can answer “the payment provider” without guessing, and can explain why an email outage has a different effect. If the answer depends on unstated assumptions, revise the labels or the promise.
Next, Design Services and Contracts Without Splitting the Monolith opens the Fieldnote box and assigns responsibilities. For the complete route and related lessons, return to Online Store Architecture: From Boundaries to Reliable Orders.