I have read some discussions in the forum about using read version as versionstamp, but to my understanding there was not a conclusive answer to this, one of the reasons being when fdb is being restored, the read version can go back.
The app my team is writing has some unique properties:
- every write will be generated by a singleton process (may be processed into fdb downstream by a multiple of processes though), it essentially generates a “write request”
- if we ever do fdb restore, we can afford to stop every writer to FDB while restore is happening
The idea I want to explore is
- return the committed version with every write
- on our main, singleton process, cache the highest version number we’ve seen and make sure any read we generate will use this as read version
This would allow us to:
- ensure we don’t suffer from “lost write” resurfacing (we had this issue where a write was “stuck” due to tls misconfiguration, then it was applied 1h later and overwrote more recent data)
- skip the get-read-version step, thus minimizing latency
Appreciate your comments