Service Calls in Microservice Architecture: RPC vs Event‑Driven, Coupling Types, and Design Strategies

In a microservice architecture, services must invoke many others to complete a function, and the two main invocation methods are synchronous RPC and asynchronous event‑driven (message) communication.

The article defines four coupling categories—time coupling, capacity coupling, interface coupling, and transmission‑method coupling—and examines how each affects system behavior, such as the need for continuous backend processing or the impact on scalability.

Event‑driven communication is broken down into two concepts: event notification (services exchange messages without direct calls) and event sourcing (persisting all state changes as events in an Event Store), highlighting their distinct roles in integration versus data storage.

An illustrative example with Order, Customer, and Product services shows how event notification can replace direct RPC calls, but also points out scenarios where tight business coupling still favors RPC, especially when immediate responses are required.

The piece discusses RPC implementations (REST, gRPC, Dubbo), their synchronous nature, and the benefits of using protocols like Protobuf gRPC for backward compatibility.

API Gateway is presented as a façade that aggregates multiple microservice endpoints, simplifying client interactions and reducing coupling at the client side.

To mitigate tight coupling, the article suggests versioning, backward‑compatible APIs, and coarse‑grained service composition, while acknowledging the operational overhead of many microservices.

It advises limiting the total number of microservices to a manageable size, using domain‑driven design (DDD) to define bounded contexts, and considering “internal microservice design”—a monolith structured internally as microservices—to ease transition and reduce deployment complexity.

Finally, the conclusion reiterates that event‑driven communication offers looser coupling, but RPC remains viable for tightly coupled business logic, and recommends starting with internal microservice design before fully adopting a microservice architecture.