Microservice Communication: Event‑Driven, Event Sourcing, RPC, and API Gateway

Event‑Driven (Event‑Driven) Approach

Martin Fowler categorises event‑driven architectures into four types, which can be simplified to two: Event Notification and Event Sourcing. Event Notification lets microservices cooperate by publishing messages instead of direct calls, while Event Sourcing records every state‑changing event in an immutable event store.

Event Notification is a communication style and should be grouped with RPC, whereas Event Sourcing is a storage technique and belongs with databases.

Event Notification (Event Notification) Method

Consider three services: Order Service, Customer Service, and Product Service. To create an Order, Order Service must read Customer and Product data. With event notification, Order Service maintains local read‑only tables for Customer and Product and synchronises them via messages.

When writing data, Order Service can emit a "Customer Created" message after Customer Service creates a new customer, allowing Order Service to update its local copy.

This example shows that event‑driven communication is most beneficial when services can operate independently. If a tight business coupling exists (e.g., an Order cannot exist without a Customer), RPC may be more appropriate.

Another shopping‑cart example demonstrates both RPC and event‑notification flows: after checkout, an "Order Placed" message triggers payment, inventory, and shipment services through a chain of messages, reducing coupling but making the overall process harder to trace.

When a business process has a fixed workflow, RPC or a BPM engine may be easier to manage; technically, event‑driven is preferable, but business requirements often dictate the choice.

Event Sourcing

Event Sourcing stores every change as an event in an Event Store, typically built on a database or message queue such as Kafka. It aligns with Domain‑Driven Design (DDD) and bounded contexts, allowing each microservice to have its own model while sharing events through streams.

Querying data from an Event Store can be done directly on small streams or by projecting events into a read‑only database for complex queries.

Advantages include full history replay and auditability; drawbacks are increased complexity, difficulty modifying past events, and the need to redesign business logic around events.

Event Notification and Event Sourcing serve different purposes: the former is an integration mechanism, the latter a persistence strategy. A system can mix both, using Event Notification for inter‑service communication and Event Sourcing for internal state.

RPC Approach

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

API Gateway

An API Gateway aggregates multiple microservice APIs into a single façade, simplifying client integration and reducing coupling by allowing changes behind the gateway without affecting clients.

Service Calls

By grouping related microservices into a coarse‑grained service, you can reduce RPC coupling similar to an API Gateway, though this approach may have limited reuse across different applications.

Reducing Tight Coupling

Tight coupling issues arise when client and server versions diverge. Solutions include supporting multiple versions simultaneously or designing services with backward‑compatible contracts, such as using Protobuf with gRPC where optional fields enable graceful evolution.

Microservice Count Limits

While there is no hard limit, an excessive number of microservices increases operational overhead. A practical guideline is to keep services small (2‑6 database tables) and avoid hundreds of services unless the organization has mature automation, observability, and deployment pipelines.

Internal Microservice Design

This approach treats a monolith as a single codebase but organises it into logical modules that resemble microservices. Each module owns its data (no cross‑module foreign keys) and can be split into independent services later.

It combines the deployment simplicity of a monolith with the architectural benefits of microservices, serving as a low‑risk entry point for organisations transitioning to a microservice architecture.

Conclusion

Microservice communication can be implemented via RPC or event‑driven methods. Event‑driven offers looser coupling, while RPC remains suitable for tightly coupled business logic and simpler code paths, especially when using backward‑compatible protocols like Protobuf gRPC. Event Notification and Event Sourcing are distinct concepts; the former integrates services, the latter persists state. The number of microservices should be kept manageable, and internal microservice design provides a pragmatic migration path.