Service Coupling, RPC vs Event‑Driven Communication, and Microservice Design Strategies

In a microservice architecture, many services must be invoked to complete a function, making service interaction a critical issue.

Service Call Methods : There are two main ways to call services—RPC (Remote Procedure Call) and event‑driven (message‑based) approaches. While message‑driven communication is loosely coupled and generally superior, RPC still has its place in suitable scenarios.

Types of Coupling : The article defines four coupling categories: time coupling (both client and server must be online simultaneously), capacity coupling (processing capacities must match), interface coupling (differences between RPC function signatures and simple messages), and sending‑method coupling (point‑to‑point vs. broadcast messaging).

Impact of Coupling : Time coupling requires immediate responses, limiting the benefit of message buffering. Capacity coupling hampers auto‑scaling when low latency is needed. Interface and sending‑method coupling expose weaknesses of RPC, especially regarding return values.

Event‑Driven (Event Notification) : Services communicate by publishing events rather than direct calls. Event notification decouples services, but when business logic is tightly coupled (e.g., an order depends on a customer), RPC may be more appropriate.

Event Sourcing : All state changes are stored as immutable events in an Event Store (often built on a database or message queue like Kafka). This enables full replay of history but introduces complexity in querying and schema evolution.

Comparison : Event notification is an integration style, while event sourcing is an internal storage mechanism. Both can coexist; some services may use event sourcing, others traditional databases.

RPC Approach : Synchronous calls (REST, gRPC, Dubbo) provide immediate results and simpler code, making them suitable for latency‑sensitive applications.

API Gateway : Acts as a façade to simplify client interactions with multiple services, reducing client‑side coupling and centralizing interface changes.

Reducing Tight Coupling : Strategies include supporting multiple versions (rarely used) and designing services to be backward compatible, often leveraging Protobuf/gRPC for optional fields.

Microservice Quantity : Excessive numbers of microservices increase operational burden; a moderate number (dozens) is manageable, while hundreds may be impractical without extensive automation.

Internal Microservice Design : A single codebase can be organized into logical microservice modules with separate databases, allowing easier future extraction into independent services.

Conclusion : Both RPC and event‑driven communication have roles; event‑driven offers loose coupling, but RPC remains useful for tightly coupled business logic, especially when using backward‑compatible protocols like gRPC. Understanding coupling types, event sourcing vs. notification, and appropriate service granularity helps architects choose the right approach.