How do microservices communicate with each other (synchronous REST vs asynchronous messaging), and what are the trade-offs?

Two fundamentally different communication styles are available between microservices, each with real trade-offs — most real systems end up using a mix of both, chosen deliberately per interaction rather than picking one style universally.

Synchronous communication (REST/HTTP, or gRPC for more performance-sensitive internal calls): Service A calls Service B and waits for a direct response before continuing.

@Service
class OrderService {
    private final RestClient inventoryClient;
    void placeOrder(Order order) {
        boolean available = inventoryClient.checkStock(order.getProductId()); // blocks until B responds
        if (available) { ... }
    }
}

• Advantages: simple to reason about — a direct request/response, immediately consistent (the caller knows the result right away), straightforward to debug (a linear call chain).
• Disadvantages: tightly couples the caller's availability and latency to the callee's — if Service B is slow or down, Service A is directly affected (and, without circuit breakers/timeouts, that slowness can cascade upstream through however many services are in the synchronous call chain); scaling requires all services in a synchronous chain to be available simultaneously.

Asynchronous messaging (via a broker like Kafka or RabbitMQ): Service A publishes a message describing what happened (or what it wants done) and moves on immediately, without waiting for any consumer to process it. One or more independent consumers process the message on their own schedule.

@Service
class OrderService {
    private final KafkaTemplate<String, OrderPlacedEvent> kafkaTemplate;
    void placeOrder(Order order) {
        orderRepository.save(order);
        kafkaTemplate.send("order-placed", new OrderPlacedEvent(order.getId())); // fire-and-forget, doesn't block on consumers
    }
}

• Advantages: decouples the publisher from the consumer's availability/latency entirely — if the inventory service is temporarily down, the message just waits in the broker until it recovers, rather than failing the original request; naturally supports multiple independent consumers reacting to the same event; generally more resilient to partial outages and easier to scale consumers independently.
• Disadvantages: eventual, not immediate, consistency — the publisher doesn't know the outcome of processing at the time it publishes, which complicates flows that genuinely need an immediate answer (e.g., "can I confirm this order right now?"); adds real architectural complexity (message ordering, duplicate delivery/idempotency handling, monitoring consumer lag, debugging a request's path across an asynchronous flow is inherently harder than following a synchronous call chain).

Practical guidance: use synchronous calls for interactions genuinely needing an immediate answer to proceed (e.g., "is this in stock, right now, to show the user"); use asynchronous messaging for side effects and cross-service reactions that don't need to block the triggering operation (sending a confirmation email, updating a reporting/analytics system, triggering a downstream fulfillment process) — this hybrid approach is far more common in real systems than a strict, one-size-fits-all choice.