Start with the problem, not the architecture

A blank canvas makes it tempting to start with familiar pieces: an API, a queue, a database. But a diagram can look convincing long before the problem is understood.

A more useful starting point is a sentence: Who needs to do what, and what gets in their way?

Ask before you draw

Imagine a small bookshop that wants to accept online orders. “We need an ordering system” is a starting point, but it leaves important questions open.

• Can two customers buy the last copy at the same time?
• What happens if payment succeeds but the order is not saved?
• Does the shop need an immediate confirmation, or can it wait a few seconds?

Each answer tells us something about the shape of the system. None of these questions requires choosing a framework.

Sketch the smallest useful flow

This diagram describes a possible order flow. The decision is visible: an order is confirmed only after a copy is reserved.

flowchart LR
accTitle: Bookshop order flow
accDescr: Check stock, reserve a copy and confirm, or show the book as unavailable.
A[Place an order] --> B{In stock?}
B -->|Yes| C[Reserve a copy]
C --> D[Confirm order]
B -->|No| E[Show unavailable]

It is deliberately incomplete. Payment, retries, and delivery need their own conversations. A small sketch gives those conversations somewhere to begin.

Put the decision in words

A short record can preserve the context that a diagram leaves out.

decision: Reserve stock before confirming an order
context: A book can have only one remaining copy
consequence: Reservations need an expiry policy
open_question: When should payment be captured?

The open question matters as much as the decision. It makes the uncertainty explicit instead of hiding it behind a tidy diagram.

Keep the next step small

Choose one realistic scenario and walk through it from the customer’s point of view. Then add a failure: an unavailable database, a repeated request, or a customer who closes the page.

A useful architecture sketch helps someone ask a better question.

The boxes can come later. First, make sure everyone is solving the same problem.