Understanding Service Coupling, RPC vs Event‑Driven Communication, and Event Sourcing in Microservices

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

Service calls can be performed via RPC or an event‑driven (messaging) approach; the latter offers looser coupling, though RPC remains useful in suitable scenarios.

Coupling types include time coupling (both client and server must be online), capacity coupling (matching processing capacity), interface coupling (RPC functions vs simple messages), and transmission coupling (point‑to‑point vs broadcast).

Each coupling type has specific impacts: time coupling requires immediate responses, capacity coupling limits buffering benefits, and interface/ transmission coupling expose RPC’s weaknesses.

Event‑driven communication, as described by Martin Fowler, consists of Event Notification and Event Sourcing. Notification uses messages for service integration, while Sourcing records all events in an Event Store, often built on databases or message queues like Kafka.

Event Sourcing stores every state change, enabling replay and historical queries, but introduces complexity, immutable event schemas, and challenges in querying large streams, often mitigated by read‑only databases synchronized from the Event Store.

Examples illustrate how Order, Customer, and Product services interact via both notification and RPC, highlighting the trade‑offs of tight versus loose coupling.

API Gateways act as facades to simplify client interactions with multiple services, reducing client‑side coupling and allowing centralized interface changes.

To mitigate tight coupling, strategies include supporting multiple versions (rarely used) and designing backward‑compatible RPC interfaces, with Protobuf gRPC offering optional fields for smoother evolution.

The number of microservices should be limited to avoid operational overhead; a moderate count (dozens) is manageable, while hundreds become burdensome.

Internal microservice design treats a monolith as a single codebase and deployment unit but structures it into modular bounded contexts, each with its own database tables, aligning with Domain‑Driven Design principles.

Conclusion: RPC and event‑driven are both viable; event‑driven provides looser coupling, while RPC suits tightly coupled business logic, especially when using backward‑compatible protocols like gRPC. Event Sourcing and Event Notification serve different purposes, and the microservice count should be kept reasonable, with internal microservice design offering a gradual migration path.