What is the difference between synchronous and asynchronous communication in distributed systems?

Why Interviewers Ask This

This question tests conceptual clarity. Interviewers want to hear a precise, confident definition before moving to more complex System Design topics. It also reveals how well you can explain technical ideas to non-experts.

Answer

Synchronous communication: the caller sends a request and waits (blocks) for the response before continuing. The two services are temporally coupled — both must be available at the same time. Examples: HTTP/REST API calls, gRPC, database queries. Pros: simple to reason about, immediate response, easy error handling. Cons: tight coupling (if B is slow or down, A waits or fails), latency accumulates across service chains, cascading failures. Asynchronous communication: the caller sends a message and does not wait — it continues processing immediately. The response (if any) arrives later via a callback, event, or polling. Examples: message queues (Kafka, RabbitMQ), event-driven architecture, webhooks. Pros: temporal decoupling (B can be down; messages queue up), better resilience, enables reactive/event-driven patterns, better throughput. Cons: complex error handling (failures are delayed), harder to debug, eventual consistency, requires idempotency. When to use sync: real-time user interactions requiring immediate response (login, payment confirmation), simple read operations, when the caller needs the result to proceed. When to use async: long-running operations (email sending, video processing), fire-and-forget operations, when operations can be retried, when decoupling is important. Common patterns: request-reply async (correlate async response via correlation ID), event-driven (services emit events, others subscribe), CQRS (separate read and write paths).

Pro Tip

If you're unsure about a detail, say so honestly and explain your reasoning. Interviewers respect candidates who can think through uncertainty rather than bluffing.