Cheat sheetCD-03

Communication Patterns

Core Design / Communication Patterns

How distributed parts talk shapes coupling and resilience: sync vs async in time, orchestration vs choreography for coordination, sagas for cross-service transactions, all governed by contracts.

01
Sync vs asyncSync blocks (temporal coupling); async sends-and-continues, decoupling availability but adding eventual consistency.
02
Orchestration vs choreographyCentral coordinator (visible, coupled) vs event reactions (loosely coupled, harder to trace).
03
SagaDistributed transaction as local transactions + compensating actions; orchestrated or choreographed.
04
ContractsAgreed message shape; strict (safe, rigid) to loose (evolvable, tolerant). Guard with contract tests.
⚑

Use synchronous calls only when you truly need the answer now; prefer async to decouple availability, accepting eventual consistency. Reach for a saga when a business transaction spans services and ACID is impossible, and decide orchestration vs choreography by weighing visibility against coupling. Version contracts and test them so producer and consumer can evolve safely.

Orchestrated sagaA Checkout Orchestrator calls reserve, charge, ship; on shipment failure it runs Refund and Release compensations.
Choreographed sagaInventory emits 'InventoryReserved', Payment reacts and emits 'PaymentCharged'; failures flow back as compensating events.
sync = block/wait; async = send/continue
orchestration = central coordinator; choreography = events
saga = local txns + compensating actions
saga != orchestration (a saga can be either)
contract strictness: strict <-> loose (safety vs evolvability)
communicationsagasorchestrationchoreographycontractsasync
review in 6d