APIs, Messaging, Events, Streams, and Workflows

What This Chapter Is About

Teach integration as the choice of communication contract, timing, coupling, delivery semantics, coordination, and failure behavior between systems.

Keep one durable idea in view:

An integration architecture is a set of explicit contracts for communication, time, ownership, and failure.

The chapter develops in this order:

Define contracts and identify temporal, deployment, and ownership coupling.
Use synchronous request-response only where an immediate answer is part of the contract.
Introduce queues, topics, and routed events for asynchronous work and fan-out.
Separate streams from events and orchestration from choreography.
Make delivery and failure behavior explicit through idempotency, retries, ordering, replay, and dead-letter handling.
Apply all choices to an end-to-end order flow.

Together, these sections show that this capability is an architecture responsibility and decision space, not a catalog of provider features.

By the end of this chapter, the reader should be able to:

Choose between APIs, queues, topics, events, streams, and workflows based on the interaction contract.
Explain the coupling and failure consequences of synchronous and asynchronous communication.
Distinguish orchestration from choreography and events from streams.
Design retry, idempotency, ordering, replay, and dead-letter behavior deliberately.
Narrate an order-processing integration design from business event to operational recovery.

The communication contract should be chosen before the provider service.
Asynchronous communication moves failure and consistency concerns; it does not remove them.
Events state what happened; commands request work; streams retain ordered records for ongoing processing.
Orchestration centralizes process visibility, while choreography distributes coordination.
Reliable integration depends on explicit duplicate, delay, ordering, replay, and poison-message behavior.