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

Coupling Types in Microservices

Four common forms of coupling affect how microservices interact:

Time coupling : the client and server must be online simultaneously to obtain an immediate response. Even when using a message queue, the consumer process must be running.

Capacity coupling : the processing capacity of the client and server must match. If the backend cannot keep up, a queue can buffer messages, but low‑latency requirements reduce the benefit.

Interface coupling : RPC exposes explicit function signatures, while messaging only transfers opaque events. A change in the RPC contract directly impacts callers.

Transmission‑method coupling : RPC is point‑to‑point and requires the caller to know the callee, enabling return values. Messaging can be point‑to‑point or broadcast, which lowers coupling but makes synchronous replies harder.

Event‑Driven Communication

Martin Fowler distinguishes two core event‑driven styles:

Event Notification (also called event‑driven integration): services exchange messages without direct calls.

Event Sourcing : every state‑changing event is persisted as an immutable record in an Event Store; the current state is rebuilt by replaying events.

These styles serve different purposes: Event Notification is an integration technique, whereas Event Sourcing is a persistence strategy.

Event Notification Example

Consider three services: Order Service , Customer Service , and Product Service . To create an order the service needs customer and product data.

Each service maintains a local read‑only table for the data it consumes.

When Customer Service creates a new customer it publishes a CustomerCreated event.

Order Service subscribes to that event and updates its local copy.

This decouples the services at runtime, but if the business rule requires an order to exist only after a customer exists, the workflow remains tightly coupled and may still be implemented with RPC.

Event Sourcing Details

Event Sourcing stores every domain event in an Event Store (commonly built on Kafka or a dedicated database). Each microservice reads from its own stream (topic) and builds read‑side projections for efficient queries.

Key challenges:

Increased code complexity: business logic must be expressed as events.

Immutable event schemas: changing an event type requires versioning because historic events cannot be altered.

Separate read models: complex queries usually need a dedicated read database that is kept in sync by listening to relevant events.

Event Sourcing is optional; a system may mix services that use traditional databases with services that use event sourcing, typically sharing a single Event Store with multiple streams.

RPC Communication

Remote Procedure Call (RPC) provides synchronous function invocation. Common implementations include REST, gRPC, and Dubbo. RPC is well‑suited for low‑latency scenarios because the caller receives an immediate result.

An API Gateway can act as a façade, aggregating multiple microservice endpoints into a single entry point. This reduces client‑side coupling and centralises version management.

Mitigating Tight Coupling

Two practical strategies are commonly used:

Multi‑version support : run several API versions concurrently. This approach incurs high operational overhead.

Backward‑compatible design : add optional parameters or new fields without breaking existing clients. Protobuf/gRPC supports optional fields and assigns numeric tags to each field, enabling safe evolution of the contract.

Example with Protobuf:

message CreateOrderRequest {
  string order_id = 1;
  // New optional field added later
  string promo_code = 2 [optional = true];
}

Existing clients can omit promo_code, while newer clients can provide it.

Guidelines for the Number of Microservices

There is no strict upper limit, but operational complexity grows with service count. A practical rule of thumb:

Each service should own 2‑6 database tables (avoid exceeding ten tables per service).

For larger organizations, dozens of services are manageable; hundreds become unwieldy.

Internal Microservice Design (Monolith with Microservice Principles)

Instead of deploying many independent services, a single codebase and database can be organized into logical modules that follow microservice boundaries:

Each module owns its own set of tables; cross‑module foreign keys are avoided.

Modules communicate via well‑defined interfaces (e.g., internal APIs or domain events).

Domain‑Driven Design (DDD) recommends a Bounded Context for each module, with duplicated but independent entity definitions to avoid shared mutable state.

Data synchronization between bounded contexts can be achieved by publishing domain events and updating read tables in each context.

This approach retains the simplicity of a single deployment while preserving the logical separation needed for future extraction into independent services.