- Transaction Audit
FoundationDB does not provide any mechanism for accessing the transaction history (it does store the last 5 seconds/5 million versions of mutations, but that’s more of an implementation detail.)
This could be implemented as a “layer”, or an abstraction built on top of the underlying kv store. You could for example never modify the keys you want a historical record of, but instead add the new value and update a pointer to it. The history of a key k might look like this:
/history/k -> 3
/history/k/1 -> value1
/history/k/2 -> value2
/history/k/3 -> value3
So to read
k you would first read /history/k and get 3, then read /history/k/3. (You probably want to store the binary representation of the version numbers or otherwise make sure it sorts by version number lexicographically). You might also want some way to encode that the value for the key is “cleared”, i.e. the key is not present.
Another approach would be to log all the writes/clears you do in each transaction in a separate keyspace within the db itself. You want to update the log in the same transaction as your actual mutations. This is roughly how backups work.
See https://apple.github.io/foundationdb/transaction-manifesto.html (in particular the transactions enable abstraction section) for FoundationDB’s philosophy here.
- Downstream systems sync
This might be a good fit for the watch feature, where you can watch for changes on a particular key. It’s more efficient than polling (although I believe the implementation does fall back to polling if there are too many watches registered)