Why RPC Beats HTTP for Scalable Backend Services

1. OSI Seven‑Layer Model

We first review the OSI seven‑layer network model (commonly simplified to five layers in practice). From top to bottom the layers are:

Application layer – defines interfaces for communication and data transfer.

Presentation layer – defines data formats, encoding and decoding rules.

Session layer – manages user sessions and logical connections.

Transport layer – handles end‑to‑end data transmission.

Network layer – defines how data is routed between devices.

Data link layer – packages network‑layer packets into frames for the physical layer.

Physical layer – transmits binary data over the medium.

In real‑world applications the presentation and session layers are usually merged into the application layer, so the focus is on the application and transport layers (HTTP is an application‑layer protocol, TCP is a transport‑layer protocol). Understanding this layering helps explain why RPC services can feel “nicer” than HTTP services.

2. HTTP Services

Historically many enterprises built services as HTTP (RESTful) APIs. For small systems with few interfaces this approach is simple, direct, and easy to develop, using the existing HTTP protocol for transport. A typical request might look like: POST http://www.test.com/restful/user/info The response is usually JSON or XML, which the client parses. However, in large enterprises with many subsystems and a high volume of interfaces, RPC frameworks provide advantages such as persistent connections (avoiding repeated TCP handshakes), built‑in service registries, monitoring, dynamic scaling, and unified management.

3. RPC Architecture

A complete RPC system consists of four core components: Client, Server, Client Stub, and Server Stub (the “stubs” act as proxies).

Client – the caller of the service.

Server – the actual service provider.

Client Stub – stores the server address, packages request parameters into a network message, and sends it remotely.

Server Stub – receives the message, unpacks it, and invokes the local method.

4. When to Use RPC

Without RPC, systems often rely on a single monolithic deployment on a web server. As user traffic grows, load balancing is introduced, but certain hot modules (e.g., a user center) may still become bottlenecks. The analogy of a school cafeteria shows that separating a popular stall (the “noodle shop”) into its own service, with dedicated bandwidth, servers, and databases, alleviates pressure on the rest of the system.

This separation is essentially a distributed architecture. The key question then becomes how the separated services communicate, since they no longer share a process. The answer is RPC, which enables inter‑process communication over protocols such as TCP or HTTP.

Performance is critical: RPC should feel as fast as in‑process calls. HTTP’s three‑way handshake adds latency (roughly 1 ms or more), and the overhead of HTTP headers and JSON payloads can be significant. High‑performance companies therefore optimize by reducing payload size, simplifying protocols, and using long‑living connections.

5. Summary

RPC services differ from HTTP services in several ways. RPC is typically chosen for large‑scale enterprises where efficiency and low latency are paramount, while HTTP suits smaller projects that prioritize rapid development. The choice of framework should be based on a thorough evaluation of project requirements rather than market trends; use RPC where its performance benefits outweigh its complexity, and use HTTP where simplicity and speed of iteration are more important.