Understanding Coupling in Microservices: RPC vs Event‑Driven Approaches

Types of Coupling

Coupling can be categorized as time coupling (both client and server must be online simultaneously), capacity coupling (processing capacities must match), interface coupling (RPC uses function signatures while messaging uses simple messages), and transmission‑method coupling (point‑to‑point RPC vs broadcast‑capable messaging).

Event‑Driven (Event‑Driven) Approach

Martin Fowler reduces event‑driven communication to two core styles: event notification and event sourcing. Event notification lets services cooperate by sending messages instead of direct calls, while event sourcing records every state‑changing event in an immutable event store.

Event Notification (Event Notification) Method

Using three example services—Order, Customer, and Product—the article shows how order creation can be handled by locally storing read‑only copies of customer and product data and synchronizing changes via messages. It highlights that when business logic is tightly coupled, RPC may still be appropriate, but event notification can decouple services at the integration layer.

Another shopping‑cart example demonstrates how each service (Checkout, Payment, Inventory, Shipment) can communicate solely through messages, reducing coupling but making the overall process harder to trace.

Event Sourcing (Event Sourcing)

Event sourcing stores every change as an event in an Event Store (often built on a database or message queue like Kafka). It enables full replay of system state but introduces complexity in event versioning and querying, often requiring a read‑only database for efficient queries.

The article clarifies that event notification is an integration technique, whereas event sourcing is an internal storage strategy; both can coexist in the same system.

RPC Method

RPC (e.g., RESTful, gRPC, Dubbo) provides synchronous remote function calls, delivering immediate results and simpler code, which is advantageous when low latency is required.

Service Gateway (API Gateway)

An API Gateway aggregates multiple microservice APIs into a single façade, simplifying client interactions and reducing coupling by allowing backend changes without client modifications.

Service Calls and Reducing Tight Coupling

Combining services into coarse‑grained composites can lower RPC coupling, but may limit reuse. Strategies to mitigate tight coupling include supporting multiple versions and designing backward‑compatible APIs, with Protobuf‑based gRPC offering strong versioning support.

How Many Microservices?

While microservices improve manageability, excessive numbers increase operational overhead. A practical guideline suggests keeping each service to a handful of database tables (2‑6, rarely more than 10) and limiting total services to a few dozen for most organizations.

Internal Microservice Design

This approach treats a monolith as a single codebase and deployment unit while internally structuring it into distinct modules that follow microservice principles, facilitating future extraction into independent services.

Conclusion

Both RPC and event‑driven communication have merits; event‑driven offers looser coupling, while RPC remains suitable for tightly coupled business logic, especially when using version‑friendly protocols like gRPC. Understanding the differences between event notification and event sourcing, and carefully sizing microservice boundaries, leads to more maintainable architectures.