# Remote procedure call (RPC) 

## Remote procedure call introduction

![](https://camo.githubusercontent.com/1a3d7771c0b0a7816d0533fffeb6eeeb442d9945/687474703a2f2f692e696d6775722e636f6d2f6946344d6b62352e706e67) 

_[Source: Crack the system design interview](http://www.puncsky.com/blog/2016/02/14/crack-the-system-design-interview/)_

In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include [Protobuf](https://developers.google.com/protocol-buffers/) , [Thrift](https://thrift.apache.org/) , and [Avro](https://avro.apache.org/docs/current/) .

## Remote procedure call in detail 
RPC is a request-response protocol:

- Client program - Calls the client stub procedure. The parameters are pushed onto the stack like a local procedure call.
- Client stub procedure - Marshals (packs) procedure id and arguments into a request message.
- Client communication module - OS sends the message from the client to the server.
- Server communication module - OS passes the incoming packets to the server stub procedure.
- Server stub procedure - Unmarshalls the results, calls the server procedure matching the procedure id and passes the given arguments.
- The server response repeats the steps above in reverse order.

Sample RPC calls:
```
    GET /someoperation?data=anId
    
    POST /anotheroperation
    {
      "data":"anId";
      "anotherdata": "another value"
    }
```

## Remote procedure call under behavior view 

RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases.

Choose a Native Library aka SDK when:

- You know your target platform.
- You want to control how your "logic" is accessed
- You want to control how error control happens off your library
- Performance and end user experience is your primary concern

HTTP APIs following REST tend to be used more often for public APIs.

#### Disadvantage(s) : RPC

- RPC clients become tightly coupled to the service implementation.
- A new API must be definied for every new operation or use case.
- It can be difficult to debug RPC.
- You might not be able to leverage existing technologies out of the box. For example, it might require additional effort to ensure [RPC calls are properly cached](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)  on caching servers such as [Squid](http://www.squid-cache.org/) .