Synchronous vs Asynchronous Communication

• Synchronous communication : the caller sends a request and blocks waiting for the response (REST, gRPC), giving immediate results but tight coupling.
• Asynchronous communication : the caller sends a message and continues without waiting (Kafka, SQS), giving decoupling and resilience but eventual rather than immediate results.
• Cascading failure : when a slow sync dependency ties up the caller's threads and brings down the whole chain.
• Circuit breaker : a pattern that stops calling a failing service after a threshold, returning a fallback instead of blocking.

What is synchronous communication?

Synchronous calls using REST or gRPC are request-response: the caller blocks until it gets a reply or times out. This is simple to reason about and ideal when the caller genuinely needs the result to continue.

package com.bank.communication;

import java.math.BigDecimal;

public class SyncBalanceClient {
    public BigDecimal getBalance(String accountId) {
        var resp = restClient.get()
            .uri("/accounts/{id}/balance", accountId)
            .retrieve().toEntity(BigDecimal.class);  // caller WAITS here
        return resp.getBody();
    }
}

What is asynchronous communication?

Async messaging using Kafka or SQS is fire-and-forget or publish-subscribe. The caller sends a message to a broker and continues immediately, while consumers process it later.

package com.bank.communication;

public class AsyncTransferPublisher {
    public void onTransferCompleted(Transfer t) {
        kafkaTemplate.send("transfer.completed", t.accountId(), toJson(t));
        // Caller continues; receipts, fraud, analytics happen later
    }
}

What are the trade-offs?

| Aspect | Synchronous | Asynchronous |
|---|---|---|
| Coupling | Tight (both must be up) | Loose (decoupled by broker) |
| Result | Immediate | Eventual |
| Failure mode | Cascading | Buffered |
| Complexity | Simple | Needs idempotent consumers |
| Use case | Balance read, auth | Notifications, analytics |

When should you use sync?

Use synchronous when the caller needs an immediate answer to proceed and the operation is a query or short command, such as authentication, balance read, or payment authorization.

When should you use async?

Use asynchronous when work can happen in the background, when you want to decouple producers from consumers, when you need to buffer spikes, or when one event must trigger many independent reactions.

How do real systems mix both?

The synchronous path does the minimum needed to answer the user correctly, and everything deferrable is pushed onto an asynchronous path. For a transfer: commit the money synchronously, publish a transfer-completed event, return success, and let receipt, fraud check, and analytics run asynchronously.

package com.bank.service;

import java.math.BigDecimal;

public class HybridTransferService {
    public TransferResult transfer(String from, String to, BigDecimal amount) {
        // SYNC: commit the money (must be immediate and correct)
        ledger.debitCredit(from, to, amount);

        // ASYNC: everything else can happen in the background
        eventBus.publish("transfer.completed",
            Map.of("from", from, "to", to, "amount", amount));

        return TransferResult.success(); // return fast
    }
}

How do you protect sync edges?

Protect synchronous calls with timeouts, retries with exponential backoff, and circuit breakers so a slow dependency cannot cascade and bring down the whole system.

package com.bank.resilience;

public class CircuitBreakerExample {
    @CircuitBreaker(name = "account-service", fallbackMethod = "fallback")
    public BigDecimal getBalance(String accountId) {
        return accountClient.getBalance(accountId); // may timeout
    }

    public BigDecimal fallback(String accountId, Exception e) {
        return cachedBalance.get(accountId); // serve cached on failure
    }
}

Why must async consumers be idempotent?

Async delivery is typically at-least-once, meaning a message can be redelivered if the consumer crashes before acknowledging. Consumers must handle duplicates gracefully by checking a message id.

What should a senior engineer know?

Designing which work is synchronous and which is asynchronous is one of the highest-leverage decisions in a distributed system. It directly determines both how fast the user-facing response feels and how resilient the system is to partial failure.