Our approach is to start with a mildly-distributed (among threads within the process) monolith based on future passing, and my impression is that any latency-se

Our approach is to start with a mildly-distributed (among threads within the process) monolith based on future passing, and my impression is that any latency-sensitive operation in a session cluster (that is, all of the sessions who are interacting directly with the same working set of processes and aggregates) can and should be supported by a single node. Rebalancing involves moving the cached aggregate (any blob, like a sqlite database or a JSON file) and/or† catching up the log (sequence of blobs) on the target node. Futures are basically trivial to serialize, so the cost of involving a second node is as little as it could be; and node consolidation can be generalized because each node's dispatcher knows how many times it has accessed a remote process, which means that consensus on who should lead its log can be reached by simply sending it to the node that has the most use for it (with load balancing achieved by nodes simply not bidding for logs when their load factor or total service time is over some threshold, or say the 60th percentile of all the nodes, or whichever of those two is higher). † In some cases it's faster to just catch up the log, rather than sending the aggregate.