Stackbook Logo
distribution-communicationestablished · high operational burden

Async Communication Patterns

Also known as: async-messaging, fire-and-forget, request-reply, event-driven, polling-vs-push

Intent

Choose the right async communication pattern: fire-and-forget, request-reply, pub/sub, streaming — trade-offs for coupling, latency, and reliability.

Problem

Sync HTTP chains create tight coupling and cascade failures. Async patterns decouple but add complexity. Which to choose?

Forces

  • Coupling: sync = temporal coupling; async = decoupled
  • Latency: async adds queue latency; sync = immediate
  • Reliability: async needs broker, retries, DLQ
  • Complexity: sync simple; async needs infrastructure

Solution

✓ When to Use

  • Decouple services (deploy independently)
  • Variable workloads (burst absorption)
  • Multiple consumers for same event
  • Long-running operations

✗ When Not to Use

  • Simple request-response (sync HTTP fine)
  • Strong consistency required (distributed tx)
  • Team not ready for async complexity

Pros

  • +Decoupling: independent deploy, scale, fail
  • +Resilience: broker buffers during outage
  • +Scalability: consumers scale independently
  • +Replay: debugging, new consumers, migration

Cons

  • Eventual consistency: hard for developers
  • Operational: broker, schema, monitoring
  • Debugging: distributed trace across async
  • Latency: queue adds ms to seconds

Cost Profile

Infrastructure

Medium — broker cluster, schema registry

Operational

High — lag monitoring, replay, schema evolution

Cognitive

High — async thinking, event modeling

Failure Modes

  • Consumer lag → stale data, delayed processing

  • Schema break → consumer crashes, data loss

  • Broker outage → producer blocks or drops

  • Duplicate events → idempotency failure

  • Event ordering violation → inconsistent state

Real-World Examples

Alternatives

  • sync-http
  • grpc
  • graphql
  • polling
  • webhooks

Related Patterns

  • event-driven-architecture
  • outbox-pattern
  • idempotency-key
  • dead-letter-queue
  • retry-with-backoff
  • webhook
  • polling

Competency Domains

distribution communicationdata statereliability opseconomics evolutiondeployment