You're correct about the reference counter, the trick is that the compiler can reduce the manipulations on the counter drastically with copy elision. C++ compil

You're correct about the reference counter, the trick is that the compiler can reduce the manipulations on the counter drastically with copy elision. C++ compilers are very good at it. That's the easy part. Now our implementation is a graph of small services (we call them nano-daemons) that slice a request into elementary tasks. nano-daemons communicate between them using messages that are copied around. This means a little memory overhead but absolutely no access contention. As you know C++ is very good at using the stack for that kind of allocation and the stack is FAST. The actual content is only copied in the final phase into the network card's buffer. The reference counting is used to make sure the data is kept alive long enough, even if a parallel removal requested arrived meanwhile. The content isn't actually manipulated in parallel. An update implies the creation of a new buffer, reducing further the contention. So in other words, if you have many parallel gets on the same data, you have, in theory, a little contention caused by the reference counter being incremented. In practice, reference counting doesn't show up in profiling (so far). Actually most time is spent in the asynchronous callbacks waiting for I/O completion, something which we are very proud of! :) We've benchmarked our software on a grid of 200 servers with 12 cores each and it does much better than other products, especially for entries larger than 8 kiB. If you think about it, you realize that somehow, at some point, you will have a bottleneck, whatever design you choose.