Is RPC Dead? Or Is It Making a Comeback ? Let’s Find Out.

For a long time, I assumed RPC(Remote Procedure Call) was one of those concepts that existed in theory but wasn’t really used in modern backend systems.

Everywhere I looked, it was all about REST APIs — build endpoints, return JSON, test with Postman. That felt like the standard way of doing things.

If REST is everywhere, why is RPC still being talked about?

But the more I explored modern backend systems and microservices, the more I realized something interesting, RPC never really disappeared, it just evolved.

So let’s understand what RPC actually is, how it compares to REST, and why it’s suddenly becoming relevant again.

What is RPC (Remote Procedure Call) ?

The idea is simple

You call a method on another machine as if it were a local method

For example, imagine writing something like this in Java:

User user = userService.getUser(1);

This looks like a completely normal method call. But internally :

• A request is sent over the network
• Another server executes the logic
• The Response comes back

RPC hides all of this complexity and makes remote communication feel like a simple function call. That’s the core idea.

How RPC Actually Works

This part confused me initially because RPC feels “magical” when you first hear about it. But internally, the flow is actually very structured. When the client calls:

User user = userService.getUser(1);

the method is intercepted by something called a client stub (or proxy). This stubs :

• Converts the request into a transferable format
• Sends it over the network
• Waits for the response

For example,

Service Definition :

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}

Client Call :

UserResponse response = stub.getUser(
    UserRequest.newBuilder().setId(1).build()
);

The server receives the request, executes the actual logic, and sends the response back. Finally, the client stub converts the response back into a Java object. That abstraction is what makes RPC powerful.

What is REST API?

REST stands for Representational State Transfer. Unlike RPC, REST is centered around resources and URLs. In REST, instead of calling methods directly, you communicate through HTTP endpoints.

For example, in a Spring Boot application:

@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
    public User getUser(@PathVariable int id) {
        return new User(id, "Brock");
    }
}

You access it using an HTTP request like -> GET /users/1

The server processes the request and usually returns JSON:

{
  "id": 1,
  "name": "Brock"
}

REST became extremely popular because it aligned perfectly with the web and HTTP. It was simple, readable, and easy to debug.

RPC vs REST — What’s the Actual Difference?

At first glance, both RPC and REST do the same thing:

• Client sends request
• Server processes it
• Response comes back

but the style is difference.

Rest Focus on → Resources You interact with URLs and HTTP methods (GET, POST, PUT, DELETE)

RPC Focus on → **Actions or Methods **Instead of thinking in terms of URLs, you think in terms of method calls.

So Why Did REST Become So Popular?

This is where things get interesting. Older RPC systems existed long before REST, but they were often:

• Complex
• Hard to configure
• Difficult to debug
• Tightly coupled

Then REST arrived and solved many practical problems. It worked beautifully with:

• Browsers
• HTTP
• JSON
• Existing web infrastructure

Developers could literally test APIs directly in the browser or tools like Postman. That simplicity helped REST dominate for years.

Then Why Is RPC Coming Back?

The answer is Modern Systems have changed. Today’s applications are no longer just frontend and backend. Now, we have :

• Microservices
• Distributed Systems
• Real time communication
• Massive Scale And in these environments, performance starts to matter a lot.

Modern RPC frameworks like gRPC improved many of the old RPC problems.

1. Better Performance
2. Great for Microservices
3. Strong Contracts (.proto Files)
4. Streaming Support

What Do Real Companies Use?

Most companies today actually use both.

• REST for public-facing APIs
• RPC internally between services

Companies like Google, Netflix, Uber etc. Heavily use RPC-style communication internally.

Conclusion

I don’t think REST is going anywhere. And I don’t think RPC is replacing it completely either. What’s actually happening is:

• REST remains excellent for public APIs
• RPC is becoming increasingly useful for internal high-performance systems

And honestly, understanding both gives a much clearer picture of how modern backend systems actually work.