When to Prefer Event‑Driven Over RPC for Microservice Communication?

Coupling Types in Microservices

Microservice communication can suffer from four main coupling issues: time coupling (both sides must be online simultaneously), capacity coupling (processing capacities must match), interface coupling (tight API contracts), and transmission‑method coupling (point‑to‑point RPC vs. broadcast‑style messaging).

Time coupling demands immediate responses, capacity coupling limits the buffering benefit of message queues, and interface/ transmission coupling expose the inherent drawbacks of RPC.

Event‑Driven Communication

Event Notification

In an event‑notification model, services do not call each other directly; they publish messages that other services consume. For example, an Order Service can emit an OrderPlaced event, which a Payment Service processes and then emits PaymentReceived. This decouples the producer from the consumer and eliminates the need for immediate replies.

Event Sourcing

Event sourcing stores every state‑changing event in an immutable Event Store (often built on a database or a message system like Kafka). The current state is reconstructed by replaying events. It offers full auditability and the ability to query any historical snapshot, but it adds complexity: business logic must be expressed as events, and changing an event schema is difficult because past events remain immutable.

Event sourcing is distinct from event notification; the former is a persistence strategy, while the latter is an integration pattern.

RPC Communication

Remote Procedure Call (RPC) treats service calls like local function calls (e.g., REST, gRPC, Dubbo). It is synchronous, returns results immediately, and is simple to implement, making it suitable when low latency is essential and the business logic is tightly coupled.

Using a version‑compatible RPC protocol such as Protobuf‑based gRPC mitigates some coupling drawbacks by allowing optional parameters and backward‑compatible interface evolution.

API Gateway

An API gateway aggregates multiple microservice endpoints into a single façade, simplifying client code. It also centralizes version management: when a service interface changes, only the gateway needs updating, reducing overall coupling.

Reducing Tight Coupling

Two main strategies address tight coupling: supporting multiple service versions (costly) or designing services to be backward compatible. Protobuf/gRPC’s optional fields enable adding new parameters without breaking existing clients.

Internal Microservice Design (Monolith‑First)

This approach keeps a single codebase, database, and deployment unit while organizing the code into logical modules that follow microservice boundaries. Each module owns its tables, avoids cross‑module foreign keys, and may have its own bounded context as defined by Domain‑Driven Design (DDD). The design eases future extraction of true microservices.

Although the monolith avoids deployment and operational overhead, it still benefits from microservice‑style modularity, making later migration smoother.

Conclusion

Microservices can communicate via RPC or event‑driven mechanisms. Event‑driven messaging offers loose coupling and resilience, but RPC remains viable for tightly coupled business flows, especially when using backward‑compatible protocols like gRPC. Event sourcing and event notification serve different purposes and should not be confused. Keep the number of microservices manageable, consider internal microservice design as a low‑risk entry point, and adopt larger services or service compositions when scaling.