Key Question

How does a Remote Procedure Call make a function on another machine look like a local call?

Deep Dive

A Remote Procedure Call (RPC) is the distributed systems equivalent of a function call. You call getUser(id) and it feels local — but behind the scenes, the call crosses the network, executes on another machine, and returns the result. The entire mechanism is designed to hide the network.

The Call Chain

Here is what happens when a client calls add(3, 4) on a remote server:

  Client Machine                 Server Machine
  ┌─────────────────┐           ┌──────────────────┐
  │   Client Code    │           │   Server Code     │
  │   add(3, 4)      │           │   int add(a,b) {  │
  │       │          │           │     return a+b;   │
  │       ▼          │           │   }               │
  │   Client Stub    │           │       ▲           │
  │   marshals args  │           │       │           │
  │   ──► [3, 4]     │           │   Server Stub     │
  │       │          │           │   unmarshals args │
  │       ▼          │           │   calls add(3,4)  │
  │   Transport      │           │       │           │
  │   (TCP/UDP)      │           │   Transport       │
  │       │          │           │       │           │
  └───────┼──────────┘           └───────┼──────────┘
          │                             │
          └───────  NETWORK ────────────┘
          Request: [3, 4]  ─────────────►
          ◄─────────────  Response: 7

Step by Step

1. Client calls local stub — The client invokes add(3, 4) on a local function. It doesn’t know the implementation is remote.

2. Client stub marshals arguments — The stub serializes the arguments 3 and 4 into a flat byte buffer (marshaling). It also packs a call ID so the server knows which function to invoke.

3. Transport layer sends — The marshaled bytes are sent over the network (usually TCP, sometimes UDP for speed).

4. Server stub receives — The server’s transport layer hands bytes to the server stub.

5. Server stub unmarshals and calls — The stub deserializes 3 and 4, looks up the function by call ID, and invokes the actual add(3, 4) on the server.

6. Result travels back — The return value 7 is marshaled and sent back to the client. The client stub unmarshals it and returns to the caller.

The RPC Functional Model

  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
  │  Caller  │──►│  Client  │──►│  Server  │──►│  Callee  │
  │ (client) │   │  Stub    │   │  Stub    │   │ (server) │
  └──────────┘   └──────────┘   └──────────┘   └──────────┘

The client stub (proxy) and server stub (skeleton) are auto-generated from an interface definition. The developer writes code against the stub as if it were local.

RPC vs REST

RPC is action-oriented: chargeCard(), sendEmail(), computeScore(). REST is resource-oriented: POST /payments, POST /emails, GET /scores/42. Choose RPC when you have distinct actions (not CRUD). Choose REST when you’re primarily creating, reading, updating, and deleting resources.

Check Your Understanding

1. What would break if the client stub and server stub were generated from different interface definitions?

2. Why is marshaling different from just writing raw bytes to a socket?

3. REST APIs use standard HTTP methods. Does this give them any practical advantage over RPC?

The “So What?”

RPC is the backbone of most distributed systems — gRPC, Java RMI, Thrift, CORBA, JSON-RPC, XML-RPC. Understanding the call chain helps you debug performance issues (where is time spent? marshaling? network? server execution?), reason about failure modes (what happens if the server crashes after step 5 but before step 6?), and choose the right communication pattern for your system.

✏️ Exercises

Exercises: Architectural Models & RPC

Exercise 1: Architecture Choice

A team is building a file-sharing application for 100,000 users. Files are read-heavy (mostly downloads), users are geographically distributed, and there is no budget for centralized infrastructure.

1. Which architectural model (client-server, P2P, multi-tier, hybrid) would you recommend?
2. What specific design decisions would you make to handle the read-heavy workload?
3. What are the top three problems you’d need to solve?

Exercise 2: RPC Call Failure Analysis

A client calls deductBalance(userID: "u42", amount: 50.00) via RPC. The client stub sends the request to the server. For each scenario below, state what happens and whether the client’s balance is correct:

1. The client stub marshals the request and sends it. The server receives it, unmarshals, calls the function (which deducts $50 from the DB), but the server crashes before sending the response.
2. The server receives the request, processes it, and sends the response. The response is lost in the network. The client times out and throws an exception.
3. The client sends the request. The server processes it and sends the response. The client receives the response. Everything works — but the network duplicates the request and the server processes it twice.

Exercise 3: Protobuf Field Evolution

You have this protobuf schema deployed in production:

message Order {
  string order_id = 1;
  string user_id = 2;
  float total = 3;
}

You want to add a string coupon_code = 4 field. Some old server instances still running don’t know about field 4.

1. Will old servers crash when they receive a message with coupon_code set?
2. A client built from the old schema processes a message that has coupon_code. What does the client see?
3. What happens if you later delete field 3 (total) and reuse its number for a new int64 total_cents = 3?