Service Communication in Microservices: RPC vs Event‑Driven, Coupling Types, and Design Patterns

In a microservice architecture, many services must cooperate to complete a function, and the core question is how these services call each other. The two main approaches are synchronous RPC calls and asynchronous event‑driven (message) communication.

The article categorises coupling into four types: time coupling (both client and server must be up simultaneously), capacity coupling (processing capacities must match), interface coupling (tight function signatures versus simple messages), and transmission‑method coupling (point‑to‑point RPC versus broadcast‑capable messaging).

It analyses the impact of each coupling: time coupling demands immediate responses, capacity coupling limits buffering benefits, and interface/ transmission coupling highlight the strengths and weaknesses of RPC versus messaging.

Event‑driven communication is described using Martin Fowler’s classification, simplified to two forms: event notification (messages for integration) and event sourcing (storing all state changes as events). Event notification is an integration technique, while event sourcing is a storage strategy built on an event store.

An example with Order, Customer, and Product services shows how event notification works, its limitations when services are tightly coupled, and how RPC can sometimes be a simpler alternative for such scenarios.

Event sourcing is detailed as a design that records every change in an immutable event store, often backed by databases or message queues like Kafka. It discusses bounded contexts, DDD, query strategies (direct stream queries or read‑model databases), and the trade‑offs of complexity and immutability.

The RPC section explains remote function calls such as RESTful, gRPC, and Dubbo, emphasizing their synchronous nature, immediate results, and ease of implementation.

API Gateway is introduced as a façade that aggregates multiple microservice APIs, simplifying client code and reducing coupling by allowing changes behind the gateway without touching each client.

Service composition is suggested as a way to group fine‑grained services into coarse‑grained ones, lowering RPC coupling at the cost of reduced reusability.

To mitigate tight coupling, the article recommends supporting multiple versions or designing backward‑compatible RPC interfaces, with Protobuf‑based gRPC highlighted as a robust solution.

Regarding the number of microservices, it warns against excessive fragmentation due to operational overhead, advises starting with larger services, and presents “internal microservice design” (DDD‑inspired monolith) as a compromise that eases future splitting.

In conclusion, both RPC and event‑driven communication have their place: event‑driven offers loose coupling and scalability, while RPC remains viable for tightly coupled business logic, especially when using compatible protocols like gRPC.