RPC chains: 5 min read

When we write applications, many of us think of REST as a common standard for inter-service communications. Yet there are many other forms of communications, RPC being one of them. It is important to note, that the choice of communication means depends on many factors like business requirements, legacy code, technologies and budget available, not to mention architectural patterns you choose.

Popular in distributed computing, RPC (remote procedure call) is a procedure where a computer program is executed in a different computer (server) while the program (the code) abstracts the connection between the client and the server.

Many of you can learn about RPC in the internet but I found it difficult to find information about “RPC chains”. I even didn’t know of its existence until recently, when I read an interesting paper at Microsoft Research. Here I want to share with you a quick preview of this paper, which I missed when looking for RPC Chains in the internet.

1. Introduction: RPC vs RPC chains

RPC chains solve the problem of performance and efficiency issues related to standard RPC, where one single task may involve several client server calls to different sites. If you look at the figure below, you can immediately notice the difference:

Figure 1: (Left) Standard RPCs. (Right) RPC chain. (link to the original paper)

RPC chains allow the client to call multiple servers in succession (A−B−E−F−C−D−A) without involving the client every time.

2. Main mechanism

As server services provided in the form of service functions (remote methods) in RPC model, they can be logically sequenced in a chain of functions specifying the next service function to execute (possibly at different servers). As authors put, they can be C# or Java methods (stored and thus retrieved from a remote repository to the service), but they cannot refer to non-local variables as they need to be compiled independently.

Figure 2: Execution of RPC chain (the image is taken from the original paper)

3. Broken chains: detection & recovery

Any server can crash during RPC chain execution. It is detected by a simple mechanism called chain heartbeats, whereby a chain periodically sends and an alive message to the client that created it, with its unique chain identifier.

If a broken chain detected, the client retransmits the request and then, thanks to cached results in each server, the process continues from the host where the chain was broken.


RPC chain combines RPC calls into a chain, thus allowing to decrease the network hops (thus smaller end-to-end latencies) and bandwidth in applications using complex nested service calls as clients don’t receive unnecessary data. For more detailed information about RPC chains, please read the original paper.

Further readings:

  1. Software Architecture Patterns: 5 minute read
  2. How to Scale Your Applications: 5 min read
  3. Caching as a part Software Architecture: 5 min read
  4. When DataViz embraces Game Development




Software Engineer, Social capitalist, Historian

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How developers were checking projects for bugs using PVS-Studio

Azure pipeline: Dynamic dependsOn

Why you must know about web accessibility

How to handle Multiple API calls in Flutter / Dart like PRO !

How to write CSS so the next developer doesn’t kill you…

Introduction to Quantum Operations

Support of Visual Studio 2017 and Roslyn 2.0

Small talk chatbots

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Orkhan Huseynli

Orkhan Huseynli

Software Engineer, Social capitalist, Historian

More from Medium

Microservices Shared Libraries — Design and Best Practices

GraphQL — Benefits for Teams

Design Patterns and Principles That Support Large Scale Systems