Why RPC Still Matters in Microservices: From Service Discovery to Governance

1. Why HTTP Is Not Sufficient for Microservice Communication

Although HTTP is the universal language of the Internet, its text‑based protocol becomes a bottleneck when services grow into complex, high‑frequency call graphs. The overhead of verbose headers, request‑parameter mapping, response parsing, and error handling turns remote calls into "glue code" that can outweigh business logic.

When a single e‑commerce order triggers calls to order, product, inventory, payment, and user services, each of which may call downstream services, the cumulative cost of HTTP’s request/response cycle becomes prohibitive.

Text‑friendly protocol : JSON/XML are easy to debug but add unnecessary bytes.

Stateless design : Each request must carry all context, leading to duplicated effort.

Standard CRUD methods : GET, POST, PUT, DELETE are simple but not optimized for inter‑service traffic.

2. RPC: Designed for Internal Service Calls

Remote Procedure Call (RPC) abstracts the boundary between local and remote invocation, allowing developers to write code that looks like a normal function call while the framework handles networking, serialization, and error handling.

Example: userService.getUserInfo(123) From the caller’s perspective this is a single line of code; the RPC framework generates a dynamic proxy that performs all underlying steps.

3. RPC Behind‑the‑Scenes Workflow

The RPC process can be divided into five logical steps:

1. Service Discovery (Registration & Discovery)

When a service starts, it registers its name, IP, and port with a registry (similar to a national bank branch directory). Callers query the registry to obtain the current list of service instances, and the registry pushes updates when instances change.

2. Serialization & Deserialization

The caller serializes the method name and arguments into a binary payload (often using Protobuf or Hessian). Binary formats are typically one‑third the size of JSON/XML and can be parsed much faster.

3. Network Transmission

RPC uses a persistent TCP long‑connection (or HTTP/2) to avoid the handshake overhead of short‑lived HTTP connections. Multiplexing allows multiple RPC frames to share a single connection, enabling parallel requests.

4. Dynamic Proxy (Client Stub)

The framework generates a proxy object that intercepts the method call, serializes the request, looks up the service address, sends the payload, and finally deserializes the response back into a Java object. This makes the remote call appear identical to a local method invocation.

5. Service Governance

To ensure reliability, RPC frameworks provide built‑in governance features:

Load balancing : Distribute calls across multiple instances using round‑robin, weighted, or least‑active strategies.

Circuit breaking : Stop calling a failing instance and return fallback values to prevent cascade failures.

Timeout & retry : Automatically retry slow calls or fail fast after a configurable timeout.

Monitoring & alerting : Track latency, success rate, and error types; trigger alerts when thresholds are breached.

4. HTTP and RPC: Complementary, Not Competing

In a mature microservice architecture, HTTP/REST is used for external traffic because of its simplicity and universal support, while RPC is employed for internal service‑to‑service calls where performance and low latency are critical.

5. Conclusion

RPC solves three core problems that HTTP alone cannot address in high‑frequency microservice environments: efficient service discovery, compact binary serialization, and robust governance. By encapsulating these complexities behind a single‑line method call, RPC enables developers to build scalable, reliable systems without sacrificing productivity.