Originally published on lavkesh.com

When designing a system that communicates across the network, you're choosing between two approaches. RPC and REST solve the same problem but from opposite angles.

RPC, or Remote Procedure Call, is about treating network calls like function calls. You invoke a remote method, saying 'execute this procedure on that machine and give me the result.' The underlying protocol can be TCP, UDP, HTTP, or something proprietary. This flexibility is both a strength and a weakness.

For example, I once worked on a project where we used gRPC for internal communication between microservices. We achieved significant performance improvements, with latency reduced by 30% and throughput increased by 25%, compared to our previous REST-based implementation. However, we had to invest considerable effort into managing server state and affinity.

RPC is synchronous by default. You send a request and wait for a response. The interface is built around methods, giving you a clear contract about what you can call and what arguments it needs. Examples include gRPC, Apache Thrift, and older systems like CORBA. RPC systems often maintain state on the server side, making them efficient for certain workloads but complicating scaling.

REST is fundamentally different. Instead of remote procedures, you think about resources. Everything is a thing you can retrieve, create, update, or delete using standard HTTP verbs. Your API isn't a menu of procedures; it's a collection of nouns accessed through GET, POST, PUT, and DELETE.

In a large-scale e-commerce platform I worked on, we used REST for our public API. We had to handle millions of requests per second, and the stateless nature of REST made it easy to scale. We were able to spin up new servers on demand, and the HTTP-based infrastructure worked seamlessly with our load balancers and CDNs. However, we had to implement caching at multiple layers to optimize performance.

The tradeoffs are clear. RPC offers flexibility in protocols used, which matters for custom performance optimizations. RPC also often has lower overhead for high-frequency, method-call style interactions. However, this flexibility comes at a cost. RPC systems are harder to reason about at scale and often require more infrastructure to handle state management and affinity.

REST's statelessness is its key feature. You can cache at every layer, put servers anywhere, and reason about what happens if one server dies. The entire web infrastructure, including proxies, CDNs, and load balancers, understands HTTP. REST uses that for free. The tradeoff is that you're constrained by HTTP's semantics, and some problems don't fit neatly into CRUD operations on resources.

Modern systems often mix both approaches. A public API might use REST because it needs to work everywhere, while internal communication might use RPC like gRPC for efficiency. The choice isn't about one being better; it's about understanding what each gives you and what it costs.