Cloud Computing Architecture Guide

Events, Messaging, Workflows, and Coordination

Goal

Choose a coordination style from intent, coupling, timing, visibility, and recovery ownership.

The Short Version

A command asks a named owner to do something. An event states that something happened. A queue holds work for one processing path; publish-subscribe distributes a fact to interested consumers; a stream retains ordered records within defined partitions for independent reading and possible replay. "Message" is the transport envelope that may carry any of these meanings.

Choose by what the sender knows, what must happen, and who owns progress. Asynchrony changes temporal coupling, but contracts, semantics, and business dependencies remain.

Three Coordination Shapes

Synchronous:  Order -> Payment -> Inventory -> response
Choreography: OrderAccepted -> Payment and Inventory react -> later facts
Orchestration: Workflow -> command each owner -> record outcomes -> compensate

Synchronous request-response fits immediate answers and short, reliable dependency paths. Long call chains multiply latency and partial-failure risk.

Choreography lets owners react independently to business facts. It fits extensible reactions where no producer should know every consumer. End-to-end progress can become difficult to see when many reactions collectively implement one business process.

Orchestration gives a workflow owner explicit state, timeouts, commands, and recovery. It adds central coordination but can clarify long-running processes, regulated steps, human intervention, and compensation. The orchestrator should coordinate owners, not absorb their business authority.

Example: Accepting an Order

After validating and persisting an order, the order boundary publishes OrderAccepted. An order workflow requests payment authorization and inventory reservation. Each command has a clear target and idempotency key. Results are facts: PaymentAuthorized, InventoryReserved, or failures.

The workflow records progress, applies timeouts, and decides whether to retry or compensate. Notifications subscribe to outcome events without controlling the transaction. Analytics reads the event stream independently. Intent, facts, and observation use different contracts because they have different owners.

Common Mistakes

  • Calling every transported object an event.

  • Building long synchronous chains across independently owned components.

  • Choosing choreography when nobody owns end-to-end recovery.

  • Assuming a broker removes schema and behavioral coupling.

  • Using a workflow engine to centralize every service's rules.

If Someone Asks You

Should this flow use events or a workflow?

"Use events to announce facts and enable independent reactions. Use a workflow when the business needs an explicit owner for progress, deadlines, decisions, and recovery. Many real flows use both: commands and results inside a workflow, then events for broader reactions."

What You Should Remember

Coordination style determines where intent, progress, and recovery ownership live.

Questions to Check Your Understanding

  1. How does an event differ from a command?

  2. Which forms of coupling remain after communication becomes asynchronous?

  3. When does orchestration justify central coordination?

Further Study