Request Paths, Integration Flows, and Data Movement

Goal

The previous section defined patterns as responsibility shapes. The next step is making those responsibilities visible. The fastest way to do that is to draw the important flows before choosing the implementation.

A pattern can look simple when it is described in words. It becomes more honest when the team draws how requests arrive, how systems coordinate, and how data moves over time.

The durable idea is:

A pattern becomes understandable when its important flows are visible.

The Short Version

Most architecture patterns contain three kinds of flow:

Flow type	What it shows	Common design questions
Request path	How a caller reaches a capability and receives a response.	Where does traffic enter? What must respond now? What is on the latency path?
Integration flow	How systems coordinate work across boundaries.	Is this an API call, command, event, stream, file, or workflow? What happens if a consumer is unavailable?
Data movement	Where data is created, copied, transformed, stored, queried, retained, and governed.	Which data is operational? Which data is analytical? Who owns quality, access, retention, and reconciliation?

A single solution can contain all three. If the diagram only shows one, the team is probably missing part of the pattern.

Three Flow Lanes

Use this simple flow vocabulary before drawing provider services:

Request path:      User -> Entry -> Runtime -> Data dependency -> Response
Integration flow:  System A -> Contract -> Broker/API/Workflow -> System B
Data movement:     Source -> Ingest -> Store -> Process -> Serve -> Govern

These lanes are not a formal notation. They are a practical thinking tool. They help a team separate immediate user experience from background coordination and longer-lived data use.

Request paths are often sensitive to latency and availability because the caller is waiting. Integration flows are often sensitive to durability, retries, ordering, duplication, and ownership because work crosses system boundaries. Data movement is often sensitive to quality, lineage, privacy, retention, and cost because data may outlive the original transaction.

Example: Commerce Checkout

Consider a commerce checkout design. The customer clicks Place Order and expects a clear response. That is the request path:

Customer -> Checkout entry -> Order capability -> Payment decision -> Order response

The architecture should keep this path focused. The customer should not wait for every downstream system to finish if the business does not require it. Fraud review, fulfillment, notification, loyalty updates, analytics, and finance reconciliation may continue after the response.

Those activities are integration flows:

Order created -> Fulfillment work
Order created -> Customer notification
Payment status -> Finance workflow
Inventory signal -> Replenishment process

The same checkout also creates data movement:

Order record -> Operational store -> Analytics pipeline -> Reporting model -> Governance and retention

If those three flows are mixed into one diagram, important decisions become blurry. The team may accidentally make checkout wait for analytics, treat every downstream update as a synchronous API dependency, or forget who owns reconciliation when records disagree.

What Flow Diagrams Reveal

Drawing flows exposes decisions that are easy to hide in prose:

Latency: which steps are inside the caller's wait time?
Consistency: which records must agree immediately, and which can converge later?
Security: where does identity, authorization, private access, or audit evidence matter?
Ownership: which team owns the contract, handler, data set, or recovery process?
Failure: what happens when a dependency is slow, unavailable, duplicated, or partially complete?
Cost: which flows scale with user traffic, fan-out, data volume, retention, or repeated retries?

This is why flow diagrams should appear before provider diagrams. Provider services are selected to implement the flow. They should not be used to hide the flow.

Common Mistakes

Drawing only the user request and ignoring asynchronous work after the response.
Treating every integration as a synchronous API call because it is easy to draw.
Hiding analytics exports, data copies, and reconciliation flows from the architecture discussion.
Combining control flow and data movement so tightly that ownership becomes unclear.
Drawing a flow without naming where security, failure handling, observability, and cost are checked.

If Someone Asks You

What should I draw first when I am trying to understand an architecture pattern?

A good answer is:

Draw the important flows first. Start with the user request path, then show integration flows that continue work across systems, then show data movement for storage, analytics, governance, and reconciliation. Once those flows are visible, service choices become easier to explain.

What You Should Remember

Draw the flow before choosing the implementation.

Questions to Check Your Understanding

What is the difference between a request path and an integration flow?
Why is data movement its own architecture concern?
How can drawing flows reveal missing security or operations decisions?