When to Choose RPC vs Event‑Driven: Decoding Service Coupling in Microservices

Introduction

In a microservice architecture many services must be invoked to complete a function. How services call each other is a key issue.

Types of Coupling

Time coupling : client and server must be up simultaneously.

Capacity coupling : processing capacity of client and server must match.

Interface coupling : RPC has function signatures, while messaging uses simple messages.

Transmission coupling : RPC is point‑to‑point and returns values; messaging can be point‑to‑point or broadcast, reducing coupling but making return values harder.

Impact analysis shows time coupling requires immediate responses, capacity coupling limits buffering benefits, and interface/transmission coupling are weaknesses of RPC.

Event‑Driven Communication

Event Notification

Services exchange messages instead of direct calls, achieving loose coupling.

Event Sourcing

All state changes are stored as events in an Event Store (often built on a database or message queue such as Kafka). It enables replaying history but complicates queries, which are solved by a read‑only database synchronized from the Event Store.

Event notification is an integration technique; event sourcing is a storage technique.

RPC Communication

Remote procedure calls (REST, gRPC, Dubbo) are synchronous and return results immediately, which is advantageous when low latency is required.

API Gateway

An API Gateway aggregates multiple microservice APIs behind a single façade, simplifying client code and reducing coupling.

Service Composition and Reducing Tight Coupling

Grouping several services into a coarse‑grained composite can lower RPC coupling, but the composite is useful only for a single application.

To mitigate tight coupling, support multiple versions or provide backward‑compatible RPC interfaces (e.g., Protobuf gRPC).

Microservice Count

Too many microservices increase operational burden. A reasonable size is a few dozen services; larger numbers require strong automation.

Internal Microservice Design

Design a monolith that internally follows microservice principles: separate modules, each with its own tables, no cross‑module foreign keys, and DDD‑style bounded contexts.

This approach eases future splitting into true microservices.

Conclusion

Both RPC and event‑driven approaches are viable. Event‑driven offers loose coupling, while RPC is simpler for tightly‑coupled business logic, especially when using a backward‑compatible protocol such as Protobuf gRPC. Event sourcing and notification are distinct concepts; keep microservice count moderate and consider internal microservice design as a stepping stone.