Understanding Service Coupling: RPC vs. Event‑Driven Approaches in Microservice Architecture

In a microservice architecture, many services must interact to complete a business function, making service invocation a critical issue.

Two main invocation methods exist: RPC (remote procedure call) and event‑driven (message‑based) communication. Message‑driven interaction is loosely coupled and generally superior, though RPC still has a place in suitable scenarios.

The article defines four types of coupling:

Time coupling – both client and server must be online simultaneously.

Capacity coupling – processing capacities of client and server must match.

Interface coupling – RPC uses function signatures, while messaging uses simple events.

Transmission‑mode coupling – RPC is point‑to‑point with return values; messages can be point‑to‑point or broadcast, reducing coupling but making responses harder.

Impact analysis shows that time and capacity coupling affect responsiveness, while interface and transmission‑mode coupling expose RPC’s limitations.

Event‑driven communication, as described by Martin Fowler, includes Event Notification (services publish events) and Event Sourcing (persisting all events as the system’s source of truth). Event Notification is a microservice integration technique, whereas Event Sourcing is a storage strategy often built on databases or message queues like Kafka.

Examples illustrate how an order‑processing workflow can be implemented with both RPC and event notification, highlighting the trade‑offs in latency, coupling, and traceability.

When business logic is tightly coupled, RPC may be preferable; otherwise, event‑driven designs reduce coupling and improve scalability. Event Sourcing offers full auditability but adds complexity, especially for queries, which often require a read‑model database.

The article also discusses API Gateways as facades that simplify client interactions with multiple services, reducing client‑side coupling and centralizing version management.

To mitigate tight coupling, two strategies are suggested: supporting multiple service versions (costly) and designing backward‑compatible RPC interfaces, with Protobuf/gRPC being the preferred technology.

Guidelines for microservice sizing advise keeping the number of services manageable to avoid excessive operational overhead, recommending a modest number of services with clear bounded contexts.

“Internal microservice design” proposes building a monolithic application that internally follows microservice principles—separate modules, independent databases, and bounded contexts—facilitating future decomposition.

In conclusion, both RPC and event‑driven approaches have their place: event‑driven offers loose coupling and resilience, while RPC provides simplicity for tightly coupled business flows, especially when using backward‑compatible protocols like gRPC. Properly managing service coupling, versioning, and architecture boundaries is essential for scalable, maintainable backend systems.