The moment a system is split across process boundaries, how its parts talk to each other becomes an architectural decision with lasting consequences. Choose synchronous calls everywhere and you couple services in time — one slow dependency stalls the whole chain. Choose asynchronous messaging without care and you trade that for complexity in ordering, error handling, and eventual consistency.

Communication patterns govern coupling, resilience, and the shape of business workflows. Getting them right is often the difference between a distributed system that degrades gracefully and one that fails as a unit.

Synchronous communication means the caller sends a request and blocks, waiting for a response — it needs the callee available now and couples the two in time. Asynchronous communication means the caller sends a message and continues without waiting; the receiver processes it later, decoupling availability but introducing eventual consistency.

For coordinating a workflow that spans services, two styles compete. Orchestration uses a central coordinator (an orchestrator) that explicitly directs each step and holds the workflow logic — easy to reason about, but the orchestrator becomes a hub of coupling. Choreography has no central brain: each service reacts to events emitted by others, so logic is distributed and services stay loosely coupled, at the cost of harder end-to-end visibility.

When a business transaction spans multiple services and cannot use a single ACID transaction, a saga coordinates it as a sequence of local transactions, each with a compensating action that semantically undoes it if a later step fails. Sagas can themselves be orchestrated or choreographed.

Underpinning all of this are contracts — the agreed shape of messages and APIs between services. Contracts range from strict (tightly specified, e.g. a rigid schema) to loose (minimal, tolerant of change), a choice that trades safety against evolvability.

An e-commerce checkout must reserve inventory, charge payment, and create a shipment across three services. A single database transaction is impossible, so the team models it as a saga.

In an orchestrated saga, a Checkout Orchestrator calls Reserve Inventory, then Charge Payment, then Create Shipment. If Create Shipment fails, the orchestrator invokes compensating actions — Refund Payment and Release Inventory — to unwind the work. All workflow logic lives in one visible place.

In a choreographed alternative, Inventory emits an 'InventoryReserved' event, Payment reacts and emits 'PaymentCharged', Shipping reacts to that; a failure triggers compensating events flowing backward. No central coordinator exists, so services couple only to events — but tracing 'what happened to order 42' now requires correlating events across services.

The payment call itself might be synchronous (block for authorization) while shipment creation is asynchronous (fire a message, confirm later), and each inter-service message adheres to a versioned contract so a change on one side does not silently break the other.

Communication patterns are where DDD's context boundaries become runtime integrations — a context map's relationship becomes a synchronous call or an event stream with a contract. They are the connective tissue of The Hard Parts' distributed transactions and data decomposition.

The coupling introduced by an orchestrator or a strict contract is exactly what Architecture Metrics measures (afferent/efferent coupling), and what evolutionary fitness functions can guard — for example, a contract test that fails the build when a producer breaks a consumer's expectations.