The VERY first thing one shall know when deciding on "How to build Reliable Server ... for serving high concurrent load"
Learning any new library is thrilling and makes a lot of new insights.
One very important insight is to undertake just right-sized & REASONABLE challenges alongside one's own learning-curve trajectory.
If Pieter Hintjens, co-father of the ZeroMQ, has written [ almost in bold ] the following remarks right upon entering into a chapter on designing any RELIABLE SERVICE, he knew pretty well WHY to precede forthcoming paragraphs on such designs with a similar highlighted warning...
- (cit.:) " ... going to get into unpleasantly complex territory here
that has me getting up for another espresso. You should appreciate
that making "reliable" messaging is complex enough that you always
need to ask, "do we actually need this?" before jumping into it.
If you can get away with unreliable, or "good enough" reliability,
you can make a huge win in terms of cost and complexity. Sure,
you may lose some data now and then. It is often a good trade-off.
..."
Nanomsg is out of doubts a great & smart library Project
The high-level philosophy thoughts brought from Pieter Hintjens books on advanced designs, that build "beyond the elementary ZeroMQ" Scaleable Formal Communication Patterns remains much the same
IMHO it is best to spend a few more weeks on ideas and design-paradigms & stories in both Pieter Hintjens' books, before moving into any coding.
Both a 400+ pages book The ZeroMQ Guide - for Python Developers, Section II., Advanced ZeroMQ, ( namely Chapters 6.2, 6.7, 7.1 and 7.5 )
and
a 300+ pages book "Code Connected Volume 1", ( namely the process of adding reliability in Chapter 5 - be it for the sake of reliability per-se or also for the sake of unlocking next levels of performace via load-balancing over a pool-of-resources )
will help anyone to start exploring this great but thrilling field of distributed system architecture & will help get perspectives needed for designing surviveable aproaches without re-exploring many dead-ends, that have already been proved to be dead-ends.