Understanding Service Coupling: RPC vs Event‑Driven Approaches in Microservices

Coupling Types

Time coupling: client and server must be online simultaneously; message queues can operate independently.

Capacity coupling: processing capacities must match; queues buffer when backend is slower.

Interface coupling: RPC uses function signatures, while messages are simple notifications.

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

Event‑Driven (Event‑Driven) Approach

Martin Fowler categorises event‑driven communication into two practical styles: event notification and event sourcing.

Event notification lets services cooperate by sending messages instead of direct calls.

Event sourcing records every domain event in an immutable event store, enabling reconstruction of any past state.

Event notification is a microservice integration technique, while event sourcing is a storage strategy that often co‑exists with a traditional database for query purposes.

Event Notification Example

Three services—Order, Customer, and Product—illustrate how data can be read and written via messages. The example shows that tightly coupled business logic (e.g., an Order requiring a Customer) may still need RPC or a higher‑level orchestrator.

A shopping checkout flow demonstrates both RPC and event‑notification implementations, highlighting that event‑driven messaging reduces coupling but makes end‑to‑end tracing more difficult.

Event Sourcing

Event sourcing stores all state changes as events in an event store (often built on a database or message queue like Kafka). It enables replaying history but adds complexity and challenges for schema evolution.

Two kinds of events exist: internal fine‑grained events used only by the owning service, and coarse‑grained events shared across services for integration.

RPC Approach

RPC (e.g., RESTful, gRPC, Dubbo) provides synchronous remote function calls, delivering immediate results and simpler code for latency‑sensitive operations.

API Gateway

An API Gateway aggregates multiple microservice APIs behind a single façade, simplifying client interactions and reducing coupling by centralising interface changes.

Service Calls and Reducing Tight Coupling

Grouping services into coarse‑grained composites can lower RPC coupling, though such composites may only serve a single application.

Mitigation strategies include supporting multiple versions and designing backward‑compatible services, with Protobuf‑based gRPC offering strong versioning support.

Microservice Quantity Limits

Too many microservices increase operational burden; a pragmatic limit is a few dozen for most companies. Proper tooling (service mesh, tracing, CI/CD) alleviates but does not eliminate this overhead.

Internal Microservice Design

This approach treats a monolith as a single codebase while organising it into modular, independently managed components, effectively applying DDD bounded contexts without separate deployments.

Conclusion

Microservice communication can use RPC or event‑driven methods; event‑driven is generally looser‑coupled, while RPC remains suitable for tightly coupled business logic, especially when combined with backward‑compatible protocols like Protobuf gRPC.

后端专属技术群
构建高质量的技术交流社群，欢迎从事编程开发、技术招聘HR进群，也欢迎大家分享自己公司的内推信息，相互帮助，一起进步！