Synchronous and asynchronous communication are the two fundamental ways microservices exchange data, each with different trade-offs around latency, coupling, and resilience.
Key Points: • Synchronous communication (REST/HTTP, GraphQL) gives an immediate response and is simple to reason about, but the caller blocks and is coupled to the callee's availability. • If a downstream service is slow or down in a synchronous chain, the failure can cascade up through every caller in the chain. • Asynchronous communication via message brokers like Kafka or RabbitMQ decouples services in time — the producer doesn't wait for the consumer to process the message. • Asynchronous messaging improves resilience and scalability since consumers can be temporarily unavailable without blocking producers, but it adds complexity around message ordering, duplicate delivery, and eventual consistency. • A well-designed system often mixes both: synchronous calls for user-facing requests needing an immediate answer, asynchronous events for background processing and cross-service coordination.
Example: A checkout flow might use a synchronous REST call to validate a credit card in real time, but publish an asynchronous "OrderPlaced" event to Kafka so the shipping and notification services can process it independently without slowing down the checkout response.
Interview Tip: A concise interview answer is:
"Synchronous calls are simple and give an immediate result but tightly couple services and can cascade failures, while asynchronous messaging through something like Kafka decouples services and improves resilience at the cost of added complexity around ordering and eventual consistency. I typically use synchronous calls where an immediate response is required and asynchronous events everywhere else."