Service Calls in Microservice Architecture: Event‑Driven, Event Sourcing, RPC and API Gateway

In microservice architectures, many services must cooperate to complete a single business function, making service invocation a critical design concern.

Coupling Types

Four kinds of coupling are identified: time coupling, capacity coupling, interface coupling, and transmission‑mode coupling. Time coupling requires client and server to be online simultaneously; capacity coupling demands matching processing capacity; interface coupling concerns function signatures; transmission‑mode coupling differentiates point‑to‑point RPC from broadcast‑style messaging.

Event‑Driven (Event‑Driven) Approach

Martin Fowler classifies event‑driven systems into event notification and event sourcing. Event notification lets services exchange messages instead of direct calls, achieving loose coupling. Event sourcing records every state‑changing event in an immutable event store, enabling replay and audit.

Event Notification Example : An Order Service reads Customer and Product data by synchronizing read‑only tables via messages; writes are performed by publishing "CustomerCreated" events that other services consume. The example shows that when business logic is tightly coupled, RPC may still be appropriate.

Event Sourcing

Event sourcing stores all domain events in an Event Store (often built on a database or Kafka). Queries can be performed directly on small streams or via a read‑only projection database that listens to events. While powerful for audit and replay, it adds complexity and makes schema evolution difficult.

RPC Approach

RPC (e.g., REST, gRPC, Dubbo) provides synchronous remote function calls with immediate results, suitable for latency‑sensitive scenarios. Using version‑tolerant protocols like Protobuf‑based gRPC can mitigate tight coupling by allowing optional parameters and backward‑compatible interface changes.

API Gateway

An API Gateway aggregates multiple microservice endpoints into a single façade, simplifying client integration and reducing the impact of interface changes.

Reducing Tight Coupling

Two strategies are suggested: supporting multiple versions (costly) or implementing backward‑compatible services (preferred). The article also recommends using coarse‑grained service compositions when appropriate.

Microservice Count Limits

Too many microservices increase operational burden. A practical guideline is to keep services small (2‑6 tables) and avoid exceeding a few dozen services for most companies. Internal microservice design—building a monolith that internally follows microservice boundaries—offers a compromise.

Internal Microservice Design

This approach treats a single codebase and database as a collection of bounded contexts, each with its own tables and modules, facilitating future extraction into independent services.

Conclusion

Both RPC and event‑driven communication have merits; event‑driven is preferred for loose coupling, while RPC remains viable for tightly coupled business logic, especially when using backward‑compatible protocols. Event sourcing is a distinct persistence strategy, not a communication mechanism. Teams should start with modestly sized services or internal microservice designs before scaling up.