Remote Procedure Calls (RPC): Complete Beginner's Guide

A Remote Procedure Call (RPC) lets a program call a function running on another computer as if it were local. You write something like getWeather("Delhi") in your code, and behind the scenes the RPC framework packages the arguments, sends them over the network, runs the real function on the server, and hands the result back. The network disappears behind an ordinary-looking function call.

It matters because modern software is built from many small services talking to each other. RPC is the glue: microservices, mobile apps talking to backends, and distributed systems use RPC-style calls thousands of times a second.

Key Concepts

• Stub — the local stand-in for the remote function. The client stub packs your arguments; the server stub unpacks them and invokes the real function.
• Serialisation — converting arguments into bytes for travel (JSON, Protocol Buffers) and back. Binary formats like Protocol Buffers are smaller and faster than text-based JSON.
• IDL — the Interface Definition Language contract (e.g. a .proto file in gRPC) listing available functions and argument types, so client and server agree.
• gRPC — Google's modern RPC framework using Protocol Buffers over HTTP/2, with streaming and strong typing; the most widely used RPC system today.
• Idempotency — a function is idempotent if calling it twice has the same effect as once. Critical because network retries can deliver a request more than once.

Formulas

• Single call latency: total = serialise + network round trip + server processing + deserialise. With 1 ms each way for serialisation, a 12 ms round trip and 3 ms of server work, one call takes about 17 ms.
• Sequential calls: N sequential calls take N × single-call time. Four calls at 17 ms each = 68 ms of waiting, one after another.
• Batched calls: combining N calls into one request takes roughly one single-call time. The same four calls batched take about 17–20 ms — roughly 4× faster, which is why APIs offer batch endpoints.

Worked Example

A checkout page makes 4 sequential RPC calls: getUser, getCart, getPrices, getOffers. Each call costs 1 ms serialise + 12 ms network + 3 ms server + 1 ms deserialise = 17 ms. How long does the page wait, and what would batching save?

1. Sequential: 4 × 17 ms = 68 ms of waiting before the page renders.
2. Batched into one getCheckoutData call, the network is crossed once: roughly 17 ms plus a little extra server time, about 20 ms.
3. Saving = 68 − 20 = 48 ms — about 70% faster, which users can actually feel. This is why experienced engineers batch chatty RPC calls.

Common Misconceptions

• "An RPC call is just like a local call." It looks like one but hides latency, partial failure and versioning. Treating it as free leads to systems making hundreds of tiny calls that crawl.
• "Retrying a failed call is always safe." Only for idempotent operations. Retrying "charge the credit card" can bill twice; retrying "get the balance" is harmless.

Real-World Applications

• Microservices: services inside large companies call each other with gRPC millions of times per second.
• Mobile apps: your phone's app calls backend functions over RPC-style APIs to fetch feeds and sync data.
• Databases: clients send queries to database servers using RPC-like protocols under the hood.

RPC hides the network behind a familiar function call, which makes distributed programming productive — but the network is still there. Count your calls, batch the chatty ones, make retries idempotent, and your services will stay fast as they multiply.