Understanding Service Calls in Microservice Architecture: RPC vs Event‑Driven, Coupling Types, and Design Strategies

In a microservice architecture, many services must be invoked to complete a single business function, making inter‑service communication a critical concern.

There are two primary ways to call services: the traditional RPC method and the event‑driven (message‑based) method, each with distinct trade‑offs.

Message‑based communication is loosely coupled and generally superior to the tightly coupled RPC approach, although RPC remains useful in scenarios where it fits well.

The article defines four kinds of coupling: time coupling (both client and server must be up simultaneously), capacity coupling (processing capacities must match), interface coupling (RPC uses function signatures while messages are simple events), and transmission coupling (point‑to‑point vs. broadcast messaging).

It then examines the impact of each coupling type, noting that time coupling often requires immediate responses, capacity coupling limits the benefits of buffering, and interface/transmission coupling expose the weaknesses of RPC.

Event‑driven architecture is introduced via Martin Fowler’s classification of event notification and event sourcing. Event notification enables services to cooperate by sending messages instead of direct calls, while event sourcing records every state‑changing event in an immutable event store.

An example with Order, Customer, and Product services illustrates event notification: the Order service reads local copies of Customer and Product data, synchronizes them via messages, and updates them when the Customer service emits a "customer created" event.

The article acknowledges that tightly coupled business logic may still require RPC, but suggests using a higher‑level orchestrator to reduce direct dependencies.

A shopping checkout scenario demonstrates both RPC and event‑driven flows, showing how each service (payment, inventory, shipment) can react to messages without waiting for synchronous responses.

Event sourcing is described as a design that stores all events in an Event Store (often built on databases or message queues like Kafka). It enables replaying historical states but introduces complexity in query handling, typically solved by maintaining a read‑model database synchronized from the event stream.

The piece clarifies that event sourcing is an internal implementation detail, distinct from event notification, which is merely an integration mechanism.

API Gateway is presented as a façade that aggregates multiple microservice APIs, simplifying client interactions and reducing coupling by centralizing interface changes.

Service composition, inspired by API Gateway ideas, can group fine‑grained services into coarse‑grained functional units, though this may limit reuse across programs.

To mitigate tight coupling, the article suggests supporting multiple versions or designing backward‑compatible RPC interfaces, with Protobuf gRPC highlighted as a robust solution.

Regarding the number of microservices, it advises keeping the count moderate (typically dozens) to avoid excessive operational overhead, noting that microservices emerged more for management convenience than technical necessity.

“Internal microservice design” is introduced as a monolithic application that internally follows microservice principles (bounded contexts, separate data models per module) and can be gradually split into true microservices when needed.

In conclusion, the article recommends event‑driven communication for loose coupling, acknowledges RPC’s role in tightly coupled scenarios, warns against confusing event sourcing with event notification, and suggests starting with internal microservice design before fully adopting a microservice architecture.