Service-to-Service Communication in Microservices: What Every Developer Should Know

I still remember the first time a junior dev I was mentoring asked me, "why did the order service just... hang for 30 seconds and then crash the whole checkout flow?" The answer had nothing to do with their code being wrong. It had everything to do with how their service was talking to another service — and nobody had ever actually taught them that part.

That's the gap this post is trying to close. Not "what is a microservice" — you already know that. This is about the part that trips up almost everyone the first time they split a monolith into services: how do these things actually talk to each other, and what breaks when they do?

We'll go through this using Spring Boot, since that's what most Java shops are running, but the concepts carry over regardless of stack.

The thing that changes the moment you split a monolith

In a monolith, calling another module is just a method call. It's fast, it's reliable, and if something goes wrong, you get a stack trace pointing at the exact line.

The moment that "module" becomes a separate service running somewhere else, that method call becomes a network call. And a network call can fail in ways a method call never does: the other service could be slow, temporarily down, overloaded, or reachable but taking 45 seconds to respond because its database is having a bad day. Your code needs to handle all of that, and most tutorials skip straight past it to show you the happy path.

So let's not skip it.

Synchronous communication: when you need the answer right now

This is the "call and wait" pattern — Service A calls Service B and blocks until it gets a response. Good for things like "check if this user is allowed to do this," where you genuinely can't proceed without the answer.

RestTemplate — you'll see this in a lot of existing codebases. It's not formally deprecated, but , including the example code for things like timeouts and filters.

WebClient client = WebClient.create("http://user-service");



UserDto user = client.get()

    .uri("/users/{id}", userId)

    .retrieve()

    .bodyToMono(UserDto.class)

    .block();

OpenFeign — if you're in a Spring Cloud microservices setup, this is probably what you actually want. You declare an interface, Feign generates the HTTP client for you, and it reads like a normal method call again. Full setup and config options are in the if you want the example code. Feign isn't going anywhere soon, but if you're picking a client for a brand-new project, it's worth a look before you default to Feign out of habit.

Asynchronous communication: when you don't need the answer right now

Not everything needs an immediate response. "Send a confirmation email after checkout" doesn't need to block the checkout request — it just needs to eventually happen. This is where message brokers come in: Service A publishes an event, Service B picks it up whenever it's ready, and the two services never have to be online at the same moment.

Kafka, with Spring Kafka (), if you want more routing flexibility than Kafka's topic model gives you:

@RabbitListener(queues = "order.created.queue")

public void handleOrderCreated(OrderEvent event) {

    emailService.sendConfirmation(event.getOrderId());

}

The real decision isn't "Kafka vs RabbitMQ" — that's a second-order question. The first question is sync vs async, and that comes down to one thing: does the caller need the result before it can continue? If yes, sync. If no, you're just adding latency and coupling for no reason by making it synchronous.

The part beginners skip and seniors get burned by anyway

This is the section that actually matters more than picking a client library.

Timeouts. If you don't set one explicitly, you may be relying on a default that's way too generous — or in some client setups, no timeout at all. A slow downstream service without a timeout on the caller side doesn't just slow you down, it can exhaust your thread pool and take down services that have nothing to do with the original problem.

WebClient client = WebClient.builder()

    .baseUrl("http://user-service")

    .clientConnector(new ReactorClientHttpConnector(

        HttpClient.create().responseTimeout(Duration.ofSeconds(3))))

    .build();

Retries. Sounds simple until you ask: is this call safe to retry? A GET usually is. A POST that charges a credit card is not — unless you've made it idempotent (idempotency keys are the usual fix). Blindly wrapping every call in a retry loop is how you get duplicate charges, not resilience.

Circuit breakers. When a downstream service is genuinely down, retrying just piles more load onto something that's already struggling — and it makes the caller's own response times terrible while it keeps trying. Resilience4j (, paired with Spring Cloud LoadBalancer — services register themselves on startup, and callers ask the registry "where's user-service right now?" instead of hardcoding an address. If you noticed http://user-service in the Feign and WebClient examples above with no port or IP — that's this in action, resolved by the load balancer at call time.

Quick decision guide

What I've actually seen go wrong in practice

The bug that gets people almost every time isn't a missing feature — it's a missing timeout. Someone calls a downstream service, doesn't set an explicit timeout, everything works fine in dev because the downstream service is fast and local, and then in production, under real load, one slow dependency quietly takes the whole request chain down with it. It's boring, it's not a "clever" bug, and it's also the single most common root cause I've run into in real incident reviews.

If you take away one thing from this post: don't add a client library and call it done. Set a timeout. Decide, explicitly, whether each call is safe to retry. Those two habits alone prevent most of the outages I've seen traced back to service-to-service calls.

What's the worst service-to-service incident you've personally debugged? I'm curious whether it was a timeout, a retry storm, or something weirder — genuinely feels like everyone in this field has one story.