Communication Patterns

11 min read · Updated 2026-04-25

Service-to-service communication is one of the load-bearing decisions in a SaaS architecture. The shape of communication determines how the system behaves under load, how it tolerates failure, and how easily it can evolve. The choices ripple through four properties at once:

Reliability
Does the system stay stable under varying loads and failures?
Performance
Request latency and throughput.
Scalability
Can it grow as load and demands increase?
Maintainability
Debuggability and ease of evolution.

The Spectrum

Synchronous
Immediate feedback, tight coupling
Caller waits for response. Simple mental model, easy to debug. Costs: tight coupling, latency propagation, cascading failures.
Asynchronous
Decoupled, fault-tolerant
Caller publishes; consumer processes when ready. Decoupled services, smoother under load. Costs: operational complexity, eventual consistency.

Real systems mix both. The skill is choosing per interaction.

Synchronous: REST APIs

HTTP REST APIs remain the foundation. Simple, debuggable, supported everywhere.

Strengths
Simple to implement and debug. Universal tooling support. Immediate feedback. Clear success/failure semantics.
Costs
Tight coupling. Latency propagation along call chains. Cascading failures.

Synchronous: GraphQL

Where GraphQL shines
Varied client needs
Mobile apps minimizing bandwidth. Complex relationship traversal. One screen needing data from many sources.
Where it bites
Operational complexity
N+1 query problems if resolvers aren't careful. Harder to cache than REST. Schema design takes effort.

Synchronous: RPC and gRPC

RPC abstracts network communication so calling a remote function looks like calling a local one. Modern implementations (gRPC) layer in strong typing, code generation, binary serialization on top of HTTP/2.

Strengths
Strong contracts catch integration errors at compile time. Efficient binary serialization. Great fit for internal service comms where you control both ends.
Costs
Browser support awkward. Opaque to humans. Requires schema management. Less universal than REST.

Asynchronous: Message Queues

Message queues decouple services by letting them exchange data without waiting for an immediate response.

Step 01
Send
Service A pushes a message onto the queue.
Step 02
Continue
A keeps working — no blocking.
Step 03
Process
Service B pulls the message when it's ready.
Step 04
Survive failure
Messages persist when B is unavailable.

This pattern significantly improves system resilience. The cost is operational: you now have a queue to monitor, dead-letter queues to drain, consumer-lag dashboards to watch.

Asynchronous: Event Streaming

Streaming platforms like Apache Kafka provide real-time data streams where services publish events as they occur, and other services subscribe to relevant streams.

Real-time analytics
Process user behavior as it happens.
System monitoring
Instrument infrastructure with structured events.
Data consistency
Propagate state changes across services through events.

The key shift is publish to a log, not call a service. Producers don’t know who’s listening; consumers can rewind, replay, and arrive late. Kafka gets a deep dive in Section 5.

Asynchronous: Pub/Sub

Pub/Sub messaging lets services broadcast events to multiple interested parties without knowing who’s listening.

              Order Service
                   │
        [purchase.completed]
        ↙       ↓        ↘
  Inventory  Email   Analytics
   Service  Service   Service

HTTP Protocol Evolution

HTTP/1.1
Universal support. Connection-per-request issues. Verbose plain-text headers. The compatibility floor.
HTTP/2
Multiplexing, binary framing, header compression. Significant performance gains; ubiquitous now.
HTTP/3
Built on QUIC over UDP. No head-of-line blocking on packet loss. Best on lossy mobile networks.

For internal service-to-service on stable networks, HTTP/2 is the modern default. For client-facing on the public internet — especially mobile — HTTP/3 has the edge.

Bidirectional: WebSockets

WebSockets provide bidirectional persistent connections between clients and servers.

Real-time chat
Instant messaging between users.
Collaborative editing
Synchronize document changes across users.
Live dashboards
Push data updates without polling.

The trade-off is operational: load-balancing persistent connections is harder, connection management gets non-trivial at scale, reconnection logic needs deliberate design.

Message Delivery Guarantees

At most once
Simple, but messages can be lost on system failures.
At least once
Default for most systems. Messages can duplicate. Consumers must be idempotent.
Exactly once
Theoretically perfect. Hard to implement; often unnecessary. Whole lesson on this in Section 5.

Order and Durability

No ordering
Maximum throughput
Messages processed in parallel. Workers pull freely. Right when each message is independent.
Ordered by partition
Practical compromise
Kafka partitions: strict order within a key (e.g., user ID), parallelism across keys. The right answer for most ordered workloads.

Global ordering is expensive and usually unnecessary. Most “we need ordering” requirements are actually “we need ordering per entity” — which partition keys give you.

Choosing the Right Pattern

The most successful applications don’t rely on a single pattern. They use the right one for each specific need:

Sync patterns
User-related operations needing immediate feedback and high consistency.
Async patterns
Background processing, event notifications, fault-tolerance improvements.
Hybrid
Sync + async combined for optimal user experience.

Recap