Why Services Communicate

In a monolith, modules call each other through in-process function calls — fast, simple, and transactional. In a distributed system, each service runs in its own process (often its own container or VM), so calling another service means crossing a network boundary. That boundary introduces latency, partial failures, and the need for explicit contracts.

Service communication falls into two broad families. Synchronous communication blocks the caller until the callee responds — like REST over HTTP or gRPC. Asynchronous communication sends a message and moves on — the receiver processes it later via a queue or event bus. Neither is universally better; the choice depends on whether the caller needs an immediate answer, whether failures should block the workflow, and how tightly coupled the services should be.

Before

Monolith — in-process call

1// One process, one database2function placeOrder(userId: string, items: Item[]) {3  const user = userRepo.findById(userId);4  const order = orderRepo.create({ userId, items });5  emailService.sendConfirmation(user.email, order);6  return order;7}

After

Microservices — network calls

1// Three separate services over HTTP2async function placeOrder(userId: string, items: Item[]) {3  const user = await userService.get(userId);4  const order = await orderService.create({ userId, items });5  await notificationService.sendConfirmation(user.email, order);6  return order;7}

Check your understanding

What does a network boundary introduce that in-process calls do not?Show answerHide answer
Answer
Latency, partial failure, and the need for explicit contracts and timeouts.
When is synchronous communication a fit?Show answerHide answer
Answer
When the caller needs an immediate answer and the operation is short-lived.
When prefer async messaging?Show answerHide answer
Answer
When the caller can continue without waiting, spikes must be absorbed, or many consumers should react to one fact.