<div dir="ltr"><div><div><div><div><div>Hi Vance,<br><br>Thanks for your reply. And I agree that dealing with these things in the client is more flexible.<br><br>> ...the clients are perfectly prepared to handle failures with retries and<br>
> failover to other service instances<br></div>Unfortunately the client software is already out there so we are also tied with a VirtualIP through Load-Balancer architecture. <br><br></div>High Availability from client requests are dealt with OK though as client will retry on failure (albeit to the same VIP) and is routed to a server which can handle it.<br><br></div>The problem is more internal gen_servers (lookup tables, global task servers, mini message queues). Small state which is periodically updated and needed to serve clients request (where data is largely same for every client). <br><br>Some Examples:<br><br>A background task which periodically fetches some information from an external system and keeps the data in its state, there can only be one task running globally (leader election?, failover?). <br><br>A  gen_server router where various data sources can add themselves so that requests get routed to the correct db-source. Either all nodes most connect to a global gen_server which holds the info or ideally the info is shared among multiple nodes. Again should I push state to database (then why use a gen_server at all?) or what sort of architecture is needed to cater for this?<br><br></div>Thanks again,<br></div>Martin<br></div>