Commands, Events, Streams, Workflows, and Files

Goal

Microservices and event-driven architecture separate systems into owned responsibilities. The next question is how those systems should communicate when work, facts, records, and processes cross team, partner, SaaS, or enterprise boundaries.

This section teaches communication meaning before selecting an integration mechanism.

The durable idea is:

Communication meaning chooses the integration pattern.

The Short Version

A weak integration design starts with a tool name: API, queue, event bus, workflow engine, stream, connector, or file share.

A stronger design starts with the meaning of the exchange:

Communication need
  -> Contract meaning
  -> Reliability model
  -> Owner and operating model
  -> Implementation mechanism

The mechanism matters, but it should answer the contract. A request for an answer, a command to do work, a fact announcement, a high-volume record stream, a long-running business process, and a settlement file are not the same architecture even when they all move data.

Communication Types

Use this table as a first-pass translation guide.

Communication Type	Meaning	Common Shape	Design Question
API	A consumer asks for information or invokes a controlled capability.	Request and response.	Who is allowed to call, and what contract do they depend on?
Command	One component asks another component to perform work.	Message, task, or operation request.	Must the work complete, and how do retries avoid duplicates?
Event	A source announces that a meaningful fact happened.	Published notification.	Who owns the fact, and who may react independently?
Stream	Producers append many records over time for consumers to process.	Ordered or partitioned record flow.	What volume, retention, ordering, and consumer position are needed?
Workflow	A process coordinates multiple steps, waits, decisions, and recovery paths.	Orchestrated state machine or process flow.	Where is process state visible, and how does recovery work?
File exchange	One system transfers a batch document or extract.	CSV, JSON, XML, EDI, flat file, or archive.	How are format, schedule, validation, acknowledgement, and reconciliation handled?
Synchronization	One system keeps another view or store aligned over time.	Replication, data pipeline, feed, or sync job.	Which system is source of truth, and how are conflicts detected?

Do not worry if some real integrations combine types. A partner onboarding process may expose an API, publish events, run workflows, exchange files, and synchronize records. The point is to name each path clearly instead of forcing the whole process into one category.

Why Meaning Beats Transport

Transport tells you how data moves. Meaning tells you what agreement the systems are making.

For example, a message on a broker could mean several things:

A command: ReserveInventory asks inventory to perform work.
An event: InventoryReserved announces that work already happened.
A stream record: InventoryLevelSample contributes to analytics over time.
A workflow step: ReviewReservationException pauses a process for human decision.

Those messages may all use similar infrastructure, but they need different contracts, owners, retries, observability, and recovery behavior.

Example: Commerce Order Processing

A commerce platform may use several integration patterns in one order lifecycle:

Customer checks out
  -> Checkout API validates cart and payment intent
  -> ReserveInventory command asks inventory to reserve stock
  -> OrderPlaced event announces the accepted order
  -> Inventory stream feeds demand forecasting
  -> Return workflow coordinates refund, warehouse, and support steps
  -> Settlement file exports finance records to ERP
  -> Support synchronization updates customer-service timeline

This architecture is not messy because it uses several communication styles. It is disciplined because each style matches a different promise.

The checkout API needs a timely response. The inventory command needs durable work handling. The order event needs subscriber independence. The inventory stream needs high-volume consumption. The return workflow needs visible state and exception handling. The settlement file needs validation and reconciliation.

Pattern Selection Questions

Before choosing a product or library, ask:

Question	Why It Matters
Does the caller need an immediate answer?	Points toward an API or another request-response pattern.
Is the message asking for work or announcing a fact?	Separates commands from events.
Must the work complete even if the receiver is slow?	Points toward durable messaging and recovery paths.
Is this a long-running process with waits and decisions?	Points toward workflow state and orchestration.
Is the volume continuous and high throughput?	Points toward streams and consumer-position management.
Is the boundary a partner, SaaS, ERP, or legacy system?	Files, EDI, batch exchange, connectors, or mediated APIs may be appropriate.
Who owns the meaning and support path?	Prevents central integration teams from owning business definitions by accident.

Common Mistakes

Treating every integration as an API call. This couples systems tightly and makes slow or unavailable dependencies harder to survive.
Calling all asynchronous communication events. Commands, events, streams, and workflow steps have different meanings.
Using file exchange without ownership and reconciliation. Files can be valid, but they still need contracts and operating rules.
Choosing tools before naming communication meaning. Service selection should follow the contract and reliability model.
Forgetting that integration paths need owners. A message nobody owns is just delayed confusion.

If Someone Asks You

How do you choose an integration pattern?

A good answer is:

Start by naming the communication meaning. Is the system exposing a request-response API, asking another system to do work, announcing a fact, streaming records, coordinating a long-running process, exchanging a file, or synchronizing state? Once the meaning is clear, choose the reliability model, contract owner, failure behavior, security boundary, and operating model. The technology comes after those decisions.

What You Should Remember

Name the communication meaning first.

Questions to Check Understanding

How is a command different from an event?
When might a workflow be better than messages alone?
Why are files still part of enterprise integration?