Catalog
concept#Architecture#Integration#Observability#Software Engineering

Communication Patterns

Patterns for information exchange between components, services, and teams; describes models, protocols and integration strategies.

Communication patterns describe recurring ways and protocols by which components, services, or teams exchange information.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Message brokers (e.g. Kafka, RabbitMQ)API gateways and service meshMonitoring and tracing systems

Principles & goals

Minimize direct coupling between componentsChoose the communication model according to consistency requirementsDefine explicit error and fallback mechanisms
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Hidden dependencies via uncontrolled topics
  • Data inconsistencies without compensation logic
  • Broker overload or bottlenecks due to wrong topology
  • Use schema registries for compatibility control
  • Define clear versioning and migration strategies
  • Instrument communication comprehensively for tracing

I/O & resources

  • Architecture and domain understanding
  • Definition of message formats and contracts
  • Platform for messaging or streaming
  • Established communication patterns and guidelines
  • Implemented integration paths with monitoring
  • Documented error and recovery strategies

Description

Communication patterns describe recurring ways and protocols by which components, services, or teams exchange information. They cover synchronous and asynchronous models, message formats, error handling and consistency strategies. Understanding these patterns reduces coupling, improves scalability and helps manage integration risks. Practical patterns include pub/sub, request-reply and event sourcing.

✔

  • Reduced coupling and improved scalability
  • Clearer separation of responsibilities
  • Better observability and traceability

✖

  • Increased complexity with asynchrony and error handling
  • Not all problems suit pure event models
  • Requires clear contracts and governance

  • Message throughput

    Number of messages processed per second; indicator of performance.

  • End-to-end latency

    Time between event creation and processing; important for responsiveness.

  • Error rate / dead-letter rate

    Share of failed messages and overflow into dead-letter queues.

E-commerce order process (event-driven)

Orders produce events that loosely couple inventory, billing and shipping.

Internal API gateway (request/reply)

Secure synchronous API calls with consistent contracts and timeouts.

Monitoring pipeline (observability)

Metrics and events are streamed and centrally analyzed to reconstruct communication traces.

1

Analyze existing communication paths and identify bottlenecks

2

Select appropriate patterns (e.g. pub/sub, request/reply, event sourcing)

3

Define schemas, contracts and SLAs

4

Introduce iteratively with monitoring and feedback loops

⚠️ Technical debt & bottlenecks

  • Ad-hoc topics without naming conventions
  • Missing schema registry indexing
  • Insufficient observability on integration paths
Broker bottleneckSchema incompatibilityNetwork latency
  • Using events as a substitute for missing business rules
  • Switching all interfaces to async at once without tests
  • Omitting monitoring and discovering issues only in production
  • Assuming asynchrony automatically solves scalability
  • Underestimating data consistency requirements
  • Missing governance for message formats
Domain modeling and interface designAsynchronous architecture and error-handling strategiesObservability and performance analysis
Scalability of message flowsLatency and consistency requirementsFault tolerance and recoverability
  • • Existing legacy interfaces constrain migrations
  • • Regulatory requirements for data storage
  • • Budget for messaging infrastructure