Microservice Communication: RPC vs Event‑Driven, Event Sourcing, and Design Strategies

In microservice architectures, services must interact to fulfill business functions, and the two primary interaction styles are RPC (synchronous remote calls) and event‑driven messaging, each with distinct trade‑offs.

The text defines four coupling categories—time, capacity, interface, and transmission coupling—and analyzes how they affect system design and responsiveness.

Event‑driven communication, as simplified by Martin Fowler, includes two core patterns: event notification (services exchange messages) and event sourcing (persisting all state changes as events in an Event Store).

Event notification enables loose coupling by allowing services to react to messages without direct calls, though it may still involve tight business coupling when one service must wait for another's outcome.

Event sourcing stores every state‑changing event, often using a dedicated Event Store built on databases or message queues, providing full auditability and the ability to replay history, but it introduces complexity in query handling and schema evolution.

RPC, exemplified by REST, gRPC, or Dubbo, offers straightforward synchronous calls with immediate results, making it suitable for tightly coupled business logic, especially when combined with backward‑compatible protocols like Protobuf gRPC.

API gateways act as facades that aggregate multiple microservice endpoints, simplifying client interactions and reducing client‑side coupling, while also serving as a point to enforce cross‑cutting concerns.

To mitigate tight coupling, strategies such as versioned APIs, backward‑compatible RPC protocols, and coarse‑grained service composition are recommended.

The article advises limiting the total number of microservices to avoid operational overhead, suggesting that moderate‑sized services or service compositions are often more manageable.

“Internal microservice design” proposes building a monolithic application that internally follows microservice principles—separate modules, bounded contexts, and isolated data stores—facilitating future extraction into independent services.

In conclusion, event‑driven messaging is generally preferred for loose coupling, but RPC remains viable for tightly coupled business processes, and adopting internal microservice design can serve as a low‑risk entry point to microservice adoption.