When to Use RPC vs Event‑Driven Architecture in Microservices?

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

There are two main communication styles: RPC (remote procedure call) and event‑driven (message‑based). Message‑based communication is loosely coupled and generally superior, though RPC still has a place in suitable scenarios.

Types of Coupling

Time coupling: client and server must be online simultaneously. With messaging, the consumer can run later while the queue holds the message.

Capacity coupling: client and server processing capacities must match. Messaging buffers excess load.

Interface coupling: RPC uses function signatures, while messages are simple notifications (e.g., a "product purchased" event).

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

These couplings affect design: time coupling often requires immediate responses; capacity coupling limits buffering benefits; tight business logic may still need RPC; and interface/ transmission‑mode coupling are weaknesses of RPC.

Event‑Driven Approach

Martin Fowler reduces four event‑driven styles to two: Event Notification (services exchange messages) and Event Sourcing (all data changes are stored as events in an Event Store, typically built on a database or message queue like Kafka).

Event Notification is an integration method; Event Sourcing is an internal storage technique.

Event Notification Example

Consider three services: Order, Customer, and Product. To create an order, the Order service must read Customer and Product data. With event notification, the Order service maintains local read‑only tables synchronized via messages.

When creating a new Customer during order creation, the UI redirects to a Customer creation page; after creation, a "customer created" message updates the Order service’s local table. This example shows that when business logic is tightly coupled, the Order service still waits for Customer creation, which may be better handled by RPC.

In a shopping checkout flow, both RPC and event notification can complete the process, but event notification allows each service to act independently after publishing messages, reducing coupling at the cost of losing a single view of the entire workflow.

Event Sourcing

Event sourcing records every state change as an event in an Event Store, enabling replay of any point in history. It offers advantages over traditional databases (full history, easy rollback) but introduces complexity, immutable events, and challenges in querying large streams, often requiring a read‑only database synchronized from the Event Store.

Event notification and event sourcing look similar but serve different purposes: the former integrates services, the latter stores data.

RPC Approach

RPC includes RESTful, gRPC, Dubbo, etc., and is typically synchronous, providing immediate results, which many applications need.

API Gateway

An API Gateway aggregates multiple microservice APIs into a single façade, simplifying client calls and potentially reducing function coupling.

Service Invocation

Applying the API Gateway concept can reduce RPC coupling by grouping services into coarse‑grained composites, though this may limit reuse across programs.

Mitigating Tight Coupling

Two main strategies: supporting multiple versions (high effort) or designing backward‑compatible RPC protocols. Protobuf gRPC offers version tolerance by allowing optional fields.

Is There a Limit to Microservice Count?

Too many microservices increase operational burden; the trend toward microservices stems from management needs rather than technical necessity. Proper automation (CI/CD, tracing, service mesh) mitigates overhead, but large numbers (hundreds or thousands) remain challenging.

Internal Microservice Design

This approach treats a system as a single monolith (one repo, one database) but internally follows microservice principles: separate modules, each with its own tables, no cross‑module foreign keys, and bounded contexts per DDD. It eases future splitting into true microservices.

Conclusion

Microservice communication can use RPC or event‑driven methods; event‑driven is generally preferable for loose coupling, while RPC suits tightly coupled business logic, especially with backward‑compatible protocols like protobuf gRPC. Event notification and event sourcing are distinct concepts. Limit microservice count, consider service composition, and start with internal microservice design if unsure.