🟢 Junior Level

Synchronous — sent a request and wait for a response (like a phone call).

Asynchronous — sent a message and forgot about it, response arrives when ready (like email).

Synchronous:
Service A → request → Service B → response → Service A (waits)

Asynchronous:
Service A → message → Queue → Service B (picks up when ready)

---

🟡 Middle Level

Synchronous

HTTP/REST:

ResponseEntity<User> response = restTemplate.getForEntity(
    "http://user-service/users/{id}", User.class, userId);

gRPC:

UserResponse user = userServiceBlocking.getUser(UserRequest.newBuilder()
    .setUserId(userId).build());

Pros:

• Simplicity
• Instant response

Cons:

• Cascading failures
• Temporal coupling

Asynchronous

Kafka:

kafkaTemplate.send("user-events", event); // Returns Future/ListenableFuture
// Can wait for broker confirmation, but usually fire-and-forget.

Pros:

• Fault tolerance
• Scalability

Cons:

• Eventual consistency
• Harder to debug

Common mistakes

1. Synchronous for long-running operations:

   HTTP request for 30 seconds → timeout
   Solution: async + polling/webhook
   

---

🔴 Senior Level

Architectural Trade-offs

Synchronous	Asynchronous
Strong consistency	Eventual consistency
Simpler	More fault-tolerant
Less latency: direct call, no broker overhead.	More throughput: broker buffers requests, consumer processes at its own pace.
Cascading failures	Buffering

Production Experience

Combined approach:

Synchronous: data reads (read)
Asynchronous: events, commands (write)

Best Practices

// If using async for critical data (payment):
// you won't know the result instantly — the user is left waiting.
// Need polling or callback, which complicates UX.
✅ Synchronous for simple read operations
✅ Asynchronous for events and commands
✅ Circuit Breaker for sync calls
✅ Idempotency for async messages

❌ Sync chains > 2 services
❌ Async for critical data

---

🎯 Interview Cheat Sheet

Must know:

• Synchronous: sent → wait for response (like a phone call), strong consistency, less latency
• Asynchronous: sent → forgot, response arrives when ready (like email), eventual consistency
• Synchronous: HTTP/REST, gRPC — simpler, but cascade failure risk
• Asynchronous: Kafka, RabbitMQ — more fault-tolerant, buffer for traffic spikes
• Combined approach: sync for reads, async for writes/events
• Synchronous for critical data (payment) — user waits for result
• Asynchronous for critical data is harder: need polling/callback

Frequent follow-up questions:

• When to choose synchronous? Simple read operations, need instant response, < 2 services in chain.
• When to choose asynchronous? Events, commands (write), background tasks, high load.
• Why cascade failure in sync? A→B→C→D, D is down → all hang → chain reaction.
• What is thundering herd? Multiple clients retry simultaneously — need jitter.

Red flags (NOT to say):

• “Synchronous is always faster” — yes, for simple cases, but cascade failure can make it slower
• “Asynchronous = fire and forget” — no, need monitoring and error handling
• “Sync chain of 5 services is fine” — no, cascade failure risk
• “Asynchronous for payments” — complicated, user left waiting

Related topics:

• [[15. How to organize communication between microservices]]
• [[5. What is Circuit Breaker pattern]]
• [[19. What is Retry pattern and how to use it correctly]]
• [[20. What is exponential backoff]]
• [[2. What is the difference between choreography and orchestration in Saga]]