Hi, I&#x27;m the author of GoshawkDB. Thanks for your questions - they&#x27;re certainly not answered on the website so I&#x27;ll do my best to answer them here and incorporate them into the website later.<p>&gt; Curious how this works at scale. For example if a node is down and N requests start blocking, is there an upper bound to N? What happens when this is reached? Does N map to a goroutine? A file descriptor? Is there timeouts?<p>The blocking actually occurs on a per-client basis: when a client submits a txn to the server to which it&#x27;s connected, that server will calculate which other server nodes need to be contacted in order for the txn to be voted on. If it cannot find enough servers due to failures then it will outright reject the txn and tell the client that there are currently too many failures going on.<p>However, the server could find the right set of server nodes and send off the txn to be voted on and send of the txn for verification and validation. Right at that point there could be further failures and so it&#x27;s not known how far those messages got. It is in this case that the txn could block as until some node recover it&#x27;s impossible to safely abort the txn. But it&#x27;s important to note that:<p>1. If a txn starts blocking, that&#x27;ll block just that txn and that client (as the client is blocked waiting on the outcome of the txn). No other part of the server or any other server is affected.<p>2. Other clients can be submitting other txns at the same time that need different un-failed nodes to proceed, and they progress just fine.<p>3. There is no global determination (yet) of whether a node is failed or not. Thus this approach can cope with really weird network issues - eg random connections between different nodes failing. There is no need for the whole remaining cluster to agree that nodes X, Y and Z are &quot;out&quot; - none of the algorithms depend on that sort of thing.<p>I hope this answers your questions.