When Should You Choose RPC vs Event‑Driven in Microservices?

Coupling Types in Microservices

Microservice interactions can suffer from four kinds of coupling: time coupling (both client and server must be up simultaneously), capacity coupling (processing capacities must match), interface coupling (RPC requires a function signature while messaging only needs a message), and transmission‑method coupling (RPC is point‑to‑point and returns values, whereas messaging can be broadcast but makes return values harder).

Event‑Driven Approach

Martin Fowler reduces event‑driven architectures to two core styles: Event Notification (services communicate by sending messages) and Event Sourcing (all state changes are persisted as immutable events in an Event Store). Event Notification is an integration technique, while Event Sourcing is a storage technique.

Event Notification Example

Consider three services: Order Service, Customer Service, and Product Service. To create an Order, the Order Service must read Customer and Product data. With event notification, Order Service maintains local read‑only tables for Customer and Product, synchronizing them via messages. Writing data (e.g., creating a new Customer) involves sending a "CustomerCreated" message that the Order Service consumes to update its local table. This example shows that when business logic is tightly coupled—such as an Order requiring a Customer—the event‑driven style does not eliminate coupling; RPC could be used instead, possibly via a higher‑level orchestrator.

A shopping checkout flow (Order → Payment → Inventory → Shipment) can be implemented with either RPC or event notification. In the event‑driven version, each service publishes a message after completing its step, and the next service reacts to that message, reducing direct dependencies but making the overall process harder to trace.

Event Sourcing

Event sourcing records every state change as an event in an Event Store (often built on a database or a message queue like Kafka). It aligns with Domain‑Driven Design’s bounded contexts, allowing each microservice to own its own event stream. Queries can be performed directly on small streams or via a read‑model database that subscribes to events. Advantages include full history replay and auditability; drawbacks are increased complexity, immutable event schemas, and the need for separate read models.

RPC Approach

RPC (Remote Procedure Call) includes RESTful APIs, gRPC, and Dubbo. It is typically synchronous, returning results immediately, which suits many applications that need instant responses and results in simpler code.

API Gateway

An API Gateway acts as a façade, aggregating multiple microservice endpoints into a single entry point for UI clients, reducing client‑side coupling. Updating a backend service’s interface often only requires changes in the gateway, not in every client.

Reducing Tight Coupling

Two main strategies are: (1) supporting multiple versions simultaneously (high effort, rarely adopted) and (2) designing backward‑compatible services. Using protocols like Protobuf with gRPC enables optional fields, allowing new parameters without breaking existing clients.

How Many Microservices?

There is no strict upper limit, but a large number increases operational burden. Microservices grew popular for management reasons rather than technical superiority. A practical guideline is to keep services small (2‑6 tables) and avoid excessive granularity; dozens to a few dozen services are manageable for most companies.

Internal Microservice Design

This pattern treats a monolith as a single code repository and database while internally structuring it into multiple logical microservices (modules). Each module owns its own tables and does not cross‑reference foreign keys. Shared concepts like "User" are duplicated with different names per module, following DDD’s bounded context principle. The approach eases deployment and operations while preserving the ability to split into true microservices later.

Conclusion

Microservice communication can be handled via RPC or event‑driven mechanisms. Event‑driven offers looser coupling and is preferable when business processes are not tightly bound, while RPC remains viable for tightly coupled logic, especially with backward‑compatible protocols like Protobuf gRPC. Event notification and event sourcing are distinct concepts; the former is an integration style, the latter a storage model. Keep the number of microservices reasonable, consider internal microservice design as a low‑risk entry point, and evolve the architecture as business needs dictate.