Not to take away from this library which looks pretty reasonable on its own, but I don’t think you actually want to do either of those things. In a large enough cluster different servers may have different views of the external service. You don’t want to blow circuits for otherwise healthy nodes just because one unhealthy node says that their circuit is blown. Along with those reasons I would be very hesitant to add that much complexity into the critical path of the request. Rate limiting is much better done by leveraging Little’s Law and increasing or decreasing the number of outbound “connections” dynamically.
Another minor quibble with the post but this statement is inaccurate and I think potentially misleading:
Conflict-resolution is the central feature of CRDTs. In fact, CRDTs are guaranteed to converge globally , meaning that the data will (eventually) be the same at every replica.
CRDTs don’t actually guarantee this. This is a guarantee that the replication protocol has to provide. Even if you assume that there’s a replication protocol underneath your CRDT that manages this correctly it’s only a valid statement if you add the sentence, “as long as there are no network partitions”. The cold hard reality of “eventually consistent systems” (meaning inconsistent systems) is that “eventually” is only theoretical. There’s always a likelihood that your system never converges. Not stating this explicitly has the potential to grossly mislead people.
