Hey @ozan, this is a great question. Let me try to answer this.
If you run badger in default mode (normal mode) and issue two write requests to two different badger DB, if one of them fails, your replicas will be out of sync. Each badger DB will have its own commit timestamp and if your requests are received in a different order on a Badger instance, they’ll have different key versions than what you would have on other replicas. I think one way of doing this would be to ensure the leader doesn’t process the next request until current one finishes. So you will have to wait until the commit completes on all the replicas.
For dgraph, we run Badger in Managed Mode (badger.OpenManaged). In this mode, dgraph sends the keys and its version to a badger instance. So you would say key:foo val:xx version:12 and badger will store the foo:xx:12. This way you can have control over what version each badger instance stores.
If a request fails for version x, you can retry it and be assured that even if you have received other requests, key foo will get a version x.
Here’s how we do this in dgraph
Please be aware that in Managed mode you will have to assign the timestamps to the keys and it requires proper handling. Dgraph performs it’s own conflict checking and other stuff to ensure we don’t commit at wrong version.
If you’re building a distributed version of badger, you might be interested in GitHub - mosuka/cete: Cete is a distributed key value store server written in Go built on top of BadgerDB. which is a distributed version badger (it runs in normal mode and I don’t know how they take care of versions).