Using read version for ordering & performance

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

I think what you said makes sense. Just one more point: after you do a fdb restore, you can use advanceversion command of fdbcli to make sure the restored cluster has advanced versions to the latest version of the original cluster.

1 Like