ADR-010, from docs/DECISIONS.md in the QuantyKube repository.
Status Partly superseded by ADR-012.
Partly superseded by ADR-012: a commit now holds a range of revisions. The change log and the layout below are unchanged.
Every etcd write is one QuantyDB commit, and its commit id is the etcd revision. A request that changes nothing, such as a transaction whose compare fails, commits nothing and takes no revision. Revision 1 is the empty store, committed when the file is created, so that every revision a client has seen can be read back.
Live keys, the change log and the store's own bookkeeping share one tree, told apart by a one byte prefix. Each log entry holds the new record and the previous one. Watches replay from the log, and storing both sides there is what makes a replay a single scan: rebuilding the previous value from snapshots would walk QuantyDB's commit chain once per event, because finding an old commit walks back from the head.
Writes are serialized, and each commit waits for two fsyncs before it answers. There is no group commit yet. QuantyDB's server batches statements into one commit (its ADR-028) and the same can be done here; it waits for a measurement that says the API server is waiting on it.
The cost: revisions are not dense. Compaction, history pruning and lease bookkeeping are commits too and take revision numbers that no key carries. etcd does not do this, but no client found so far depends on consecutive revisions. The log also doubles what an update writes, since the old value is stored a second time.