I should elaborate a bit on RPC issues: RPC is somewhat of a misnomer, it's a fallacy ("fallacy of distributed computing") to think that a remote method call is

I should elaborate a bit on RPC issues: RPC is somewhat of a misnomer, it's a fallacy ("fallacy of distributed computing") to think that a remote method call is the exact same thing as a local method call (anyone who has built a serious system using Java RMI or Spring RPC -- which hacked InvocationContext/used AOP to intercept local method calls and turned them into remote calls -- can confirm this). Instead successful RPC wrappers tend to follow two patterns: 1) Thin client, with heavy lifting done on a server side proxy written in the same language as the original client. This is the pattern we followed with Voldemort when I was at LinkedIn -- there was a heavy Java RPC client (which had a lot of client logic) and thin clients that (like parts of the Java client) used protobuf over the wire, but contained much less logic. Problem with this is that it adds an extra hop (latency issue) and at times interface mis-match viz. local clients. 2) Only expose the protocol via the RPC, write a first-class implementation (given the full blown protocol) in major languages. Practically this means native "fat" client (whether in Java or C++) uses the full RPC wire protocol (but may use a higher performance server implementation) and works in the case where major languages are Java (or JVM-based) and C/C++: Python/Ruby/PHP/etc... use Swig or custom extensions to use the C++ client, Java has its own native client built in parallel. If you add another language without FFI to either Java or C/C++ to the mix (or there's significant velocity mismatch between team working on the Java-based vs. C++ based clients/server) maintenance becomes an issue. This is an approach I was following on my last project at FB with HBase (I've since left FB and am elsewhere, but the work is continuing and will likely be open sourced) for another distributed system -- where the proxy Thrift service always lagged behind the native client and where most heavy C/C++ based clients built their own thrift proxies to talk to HBase. Upstream HBase (and HDFS) -- FB has its own (open sourced) branch -- has also followed a similar approach with converting the native protocol to use protocol buffers for SerDe.