How do microservices communicate with each other?

Direct Answer

Microservices use synchronous request/response protocols such as HTTP or gRPC and asynchronous messaging such as queues or event streams. Synchronous calls create temporal and availability coupling but give an immediate result. Asynchronous communication can buffer work and decouple timing, yet delivery semantics, ordering, retries, idempotency, and observability must be designed.

Code Example

// Synchronous: call another service and WAIT for the response (REST)
@Service
class OrderService {
    private final WebClient payment;
    public PaymentResult charge(Order order) {
        return payment.post().uri("/charge")
            .bodyValue(order).retrieve()
            .bodyToMono(PaymentResult.class)
            .block(); // blocks until PaymentService answers
    }
}

// Asynchronous: publish an event and move on (Kafka) — consumers react later
@Service
class OrderEvents {
    private final KafkaTemplate<String, OrderPlaced> kafka;
    public void publish(Order order) {
        kafka.send("orders", new OrderPlaced(order.id())); // fire and forget
    }
}

Common Mistakes & Pitfalls

• Overusing synchronous calls: Freshers often chain REST calls like OrderService calls InventoryService, which calls WarehouseService, which calls ShippingService. Each hop adds latency and multiplies failure risk—if any service in the chain is slow or down, the entire request fails. This creates a brittle system.
• Not handling timeouts: Making a REST call without setting a timeout means if the other service hangs, your thread blocks forever. In production, you need circuit breakers like Resilience4j to fail fast when a service is unhealthy.
• Ignoring idempotency in async: With message brokers, the same message might be delivered twice (at-least-once delivery). If your code doesn't check for duplicates, you might charge a customer twice or send the same email repeatedly. Freshers forget to design handlers to be idempotent.