Part 3 — Advanced RPC Concepts, Comparisons & Delivery Semantics

(maang.io System Design Series)

What is this?

Parts 1 and 2 kept circling one uncomfortable fact: a remote call can succeed on the server while looking like a failure to the client. We named it (partial failure), we drew it (the lost-response timeout), and we built machinery around it (deadlines, retries, circuit breakers). Now we pay the question off properly.

This chapter does two things. First, it places RPC among its rivals — REST, message queues, WebSockets — so you know when to reach for it. Second, and more importantly, it confronts the deepest question in all of distributed communication: if I send a request and retry it after a timeout, how many times does the work actually happen — zero, one, or more? That's the question of delivery semantics, and the answer reshapes how you design every important RPC you ever write.

The one-line idea: the network's leaky abstraction forces a choice between at-most-once and at-least-once delivery; true exactly-once is a fiction you manufacture by making operations idempotent — and that single design discipline is what makes retries safe.