Understanding Service Coupling: RPC vs Event‑Driven Approaches in Microservice Architecture

In a microservice architecture, completing a business function often requires invoking many services, making the method of service calls a critical design decision.

There are two primary communication styles: synchronous RPC (e.g., REST, gRPC, Dubbo) and asynchronous event‑driven messaging. Messaging provides loose coupling, while RPC offers tighter coupling but can be appropriate for certain scenarios.

Types of coupling include time coupling (both client and server must be online), capacity coupling (processing capacities must match), interface coupling (function signatures vs. simple messages), and transmission‑method coupling (point‑to‑point vs. broadcast). Each type influences latency, scalability, and fault tolerance.

Event‑driven (Event‑Driven) approach

Martin Fowler categorises event‑driven communication into two essential forms: Event Notification and Event Sourcing. Event Notification lets services cooperate by publishing messages instead of direct calls. Event Sourcing records every domain event in an immutable Event Store, enabling replay and audit.

Event Notification example

Consider three services – Order, Customer, and Product. When creating an Order, the Order service must read Customer and Product data. Using event notification, the Order service maintains local read‑only tables for Customer and Product, synchronising them via messages. For writes, the Order service can emit a "CustomerCreated" event that other services consume to update their local copies.

While this demonstrates loose coupling, the example also shows that tightly coupled business logic (e.g., an Order cannot exist without a Customer) may still require RPC or a higher‑level orchestrator.

RPC approach

RPC is a remote function call that is typically synchronous, allowing immediate results. It is simple to implement and works well when low latency is required. Protocols like Protobuf‑based gRPC provide versioning and backward‑compatibility features that mitigate some tight‑coupling drawbacks.

API Gateway

An API Gateway aggregates multiple microservice endpoints into a single façade, reducing client‑side complexity and lowering coupling between UI and individual services. Updating the gateway can shield clients from downstream interface changes.

Reducing tight coupling

Two main strategies are supporting multiple API versions (costly) or designing backward‑compatible services (preferred). Using gRPC with optional fields enables new functionality without breaking existing clients.

Microservice count considerations

Having too many microservices increases operational overhead. A practical limit is a few dozen services for most organisations; beyond that, management and monitoring become burdensome. The decision to adopt microservices should be driven by management needs rather than pure technical novelty.

Internal microservice design (DDD)

Domain‑Driven Design advocates bounded contexts, where each context owns its data model and database tables. An "internal microservice design" treats a monolith as a single codebase but organises it into modules that follow microservice principles, easing future extraction.

This approach combines the deployment simplicity of a monolith with the architectural benefits of microservices, allowing gradual migration when business needs dictate.

Summary

Microservice calls can be implemented via RPC or event‑driven messaging. Event‑driven communication offers looser coupling and better scalability, but RPC remains useful for tightly coupled business logic, especially when combined with backward‑compatible protocols like gRPC.