<div dir="ltr"><div>Hi.</div><div><br></div><div>- use riakc protobuf client or join services and Riak ring in a common</div><div>erlang cluster with the same cookie?</div><div><br></div><div>R// Definitely use riak protobufs, is the mainstream, maintained and optimized by Basho</div><div><br></div><div>- open a new connection from riakc to Riak node on each hit or keep a</div><div>connection pool? I suppose it should be the pool as sockets are finite.</div><div><br></div><div>R// Definitely you should use a connection pool</div><div><br></div><div>- on every request connect to a random Riak node from the ring? Or use</div><div>dedicated Riak nodes for each service instance, if there are many?</div><div><br></div><div>R// I'd say: it depends on what you really need AND the option that fits better with your systemic properties. One common case could be use a load balancer, take a look at this link: "<a href="http://docs.basho.com/riak/latest/ops/advanced/configs/load-balancing-proxy">http://docs.basho.com/riak/latest/ops/advanced/configs/load-balancing-proxy</a>". On other hand, depending of your context, is not bad to have a symetric topology as you mentioned, having a Riak node per Service/Server node, as long as you have a same symetric traffic over your resources, because in top of the server nodes I suppose that you will have a load balancer, so the traffic will be distributed symetrically over the Riak nodes too. And the other option is quite similar, picking a random Riak node from the client, using some balancing strategy.</div><div><br></div><div>- what to do with the new nodes which are joining the ring and the ones</div><div>which are removed from the ring? What is the more or less standard way to</div><div>notify clients about this?</div><div><br></div><div>R// The idea is don't do anything -- as far as possible. Riak handles this, it is an internal Riak process. Also it could be an admin task, but not to deal with it from your client (in this case is what you call service instance). You can read more about it: <a href="http://docs.basho.com/riak/latest/ops/running/handoff/">http://docs.basho.com/riak/latest/ops/running/handoff/</a></div><div><br></div><div>- what to do in a client if a Riak node temporarily goes offline? Keep</div><div>trying to connect to such node until it gets online again? This would</div><div>obviously hit latency unless there's a special dedicated process for this.</div><div><br></div><div>R// This is one of the drawbacks when you have one-to-one connections (Riak node per Service node). And you would have to handle re-connection attempts as you mention, but the idea is the timeout between attempts be longer each time (e.g.: using a linear or exponential factor), and in this way avoid to hit the DB to much. Again, probably the recomendation here is to use the load balancer approach (mentioned previously), because your service instances are pointing to the LB not directly to the DB, so if some Riak node goes down, the upcoming requests will be distributed on the rest of the available Riak nodes.</div><div><br></div><div>Finally, I strongly recommend to use 'sumo_db' (<a href="https://github.com/inaka/sumo_db">https://github.com/inaka/sumo_db</a>), which will make easier interact with Riak, and also avoid to deal with some things like connection pools, configuration, complex search, etc.</div><div><br></div><div>C. Andres Bolaños<br></div></div>