Communication Models

Why communication models matter

Imagine two friends coordinating a meetup: one calls and waits on the line, the other sends a text and goes on with their day. Distributed systems face the same choice. A communication model describes how processes exchange messages across machines: whether they wait, whether delivery timing is predictable, and whether sender and receiver must act at the same moment.

In a single computer, a function call feels instant. In a distributed system, a message may cross a network, hit a queue, or be delayed by 200 ms—or 20 seconds. That gap changes design.

Common questions a communication model answers:

• Does the sender block until a reply arrives?
• Must both sides be active at the same time?
• Can messages be buffered or queued?
• What assumptions can we make about delay?

These choices affect latency, throughput, fault tolerance, and user experience.

Synchronous vs. asynchronous

Think of synchronous communication like a phone call: both sides are engaged now, and the caller often waits for an answer. In distributed systems, this often appears as request-response: service A sends a request to service B and blocks until B replies or times out.

Asynchronous communication is more like email or a parcel drop-off. The sender hands off a message and continues. The receiver may process it later, often through a message queue like RabbitMQ or Kafka.

A rough response-time model for synchronous calls is:

total time = network send + processing + network reply

Example:

• send: 40 ms
• processing: 120 ms
• reply: 40 ms
• total: 200 ms

If service A makes 5 such calls in sequence, the user may wait about 5 × 200 = 1000 ms, or 1 second.

Coupling, timing, and failure behavior

Communication models differ in coupling. With synchronous calls, services are tightly coupled in time: if service B is slow, service A feels it immediately. If B is down, A may fail too unless it has retries, timeouts, or fallbacks.

Asynchronous systems loosen that tie. A sender can publish an event—OrderCreated—and move on. Receivers subscribe and react when ready. This improves scalability, but it introduces new questions:

• How long can messages sit in a queue?
• What if the same message is delivered twice?
• How do we know when processing is complete?

A tiny contrast:

# synchronous
price = pricing_service.get_price(item_id)

# asynchronous
queue.publish({"event": "OrderCreated", "orderId": 4812})

The first expects an immediate result. The second hands off work for later handling.

Choosing the right model

There is no universal winner. Good distributed systems often mix both models. Use synchronous communication when a user or service needs a result now: login checks, payment authorization, fetching a profile. Use asynchronous communication when work can happen later: sending emails, generating reports, updating search indexes.

A practical rule of thumb:

• Choose synchronous for low-latency, immediate dependencies
• Choose asynchronous for background work, burst handling, and failure isolation
• Add timeouts to synchronous calls
• Add idempotency to asynchronous handlers so duplicates are safe

The big idea: communication models are not just plumbing. They shape how failures spread, how fast systems feel, and how independently teams can build services.