Count the operations in the documented write path. A `set()` builds the record, appends it to the log, waits for `File::sync_all()` to return, and only then touches the memtable [5]. That ordering is the guarantee rather than an implementation detail, because the in-memory structure never holds a write the disk has not accepted [5]. It also puts the barrier inside any throughput figure the store reports. At 765,846 acknowledged writes per second, the store is completing 765,846 `sync_all()` calls per second [14], which is about 1.31 microseconds per write [13].
Redo that division before you read anybody's fix. For the figure to describe a durable store on your hardware, `sync_all()` would have to return in roughly the time of a buffer copy, on your filesystem, with your device's write cache doing whatever it does when nothing asks it to flush. The excerpt I have does not spell out what the benchmark got wrong, but the budget narrows the options: either the barrier sat outside the timed loop, or it was satisfied by a cache that had not reached stable storage. Both of those produce a page cache benchmark with a Rust API in front of it.
The 64 MiB field-size bound is the same lesson one layer down. A guard in `decode()` runs on the read path, which is after the fsync; a guard in `encode()` runs before the append [7]. With the ceiling on only one side, the durability machinery behaved exactly as specified and made permanent a record the reader would refuse, at 9.4 percent over the bound [15]. The author's own conclusion is the right one: rejecting at the door beats persisting data you will later classify as corruption [9].
Putting the CRC at the end of a variable-length record [6] is what makes a torn tail detectable at all, since a record whose last bytes never landed cannot verify. The price is 13 bytes of fixed framing per record, one byte of op, two four-byte length fields, and four bytes of checksum [16]. On small values that overhead is not noise, and it is worth pricing separately from the fsync when you compare stores.
None of the architecture is new, and the author says so plainly [12]. The part worth copying is the single falsifiable sentence and the scope note under it: process crash, not power loss, and no claim beyond what `sync_all()` promises on the filesystems he actually tested [11][3]. In my context I would rather adopt a store that names the fault it has not injected than one whose guarantee is phrased loosely enough that no test could fail it. That disclosure is worth more than the writes-per-second line, which is the first thing I would cut from the README.
