Part 2 — RPC Architecture, Protocols & Internals

(maang.io System Design Series)

What is this?

In Part 1 you watched a call travel: stub → marshal → transport → skeleton → unmarshal → execute → and back. That was the story. This chapter is the machinery — the parts a real RPC framework bolts together to make that story survive production traffic.

Keep the phone-call analogy from Part 1 alive. Calling a colleague to do a task is the idea. But a real call center needs more: a shared language so both sides understand the request (serialization), phone lines that don't drop (transport), a directory so you can find who to call (service discovery), an operator routing calls to whoever's free (load balancing), and a policy for what to do when nobody picks up (resilience). Strip any one of those out and the elegant idea collapses the first time something goes wrong.

The one-line idea: the elegance of "just call a function" rests on a stack of unglamorous machinery — encoding, transport, discovery, balancing, and resilience — and senior engineers are paid to understand that machinery, because it's what leaks when the network misbehaves.

Let's go layer by layer.