Per-shard GenServer that buffers transactions and writes to ObjectStorage.

Each ShardServer handles a single shard's transaction stream:

1. Receives transaction slices from Demux
2. Buffers in memory with newest at head
3. Obeys {:flush, cut_version} commands from Demux, persisting everything at or below the cut as one chunk via the async persistence queue
4. Notifies waiting materializers via WaitingList
5. Reports durability to Demux only after persistence confirmation

Commanded cuts

ShardServers never decide when to flush. Demux computes deterministic cut versions (pure version arithmetic — versions are microsecond timestamps) and commands flush/2. Because every replica of a shard sees the same slices and the same cuts, the resulting chunks are byte-identical, which is why put_if_not_exists returning {:error, :already_exists} counts as a successful confirmation.

On a cut the server reports its floor contribution — the cut version itself, meaning "everything I have ever seen at or below this version is durable" — not the max flushed data version. An empty buffer confirms the cut immediately, so idle shards never pin the WAL trim floor.

Chunks are named for the last commit they contain (c/{shard}/{inverted(max_contained)}), preserving the cheap next-key-after seek contract for readers.

Pull API

Materializers call pull/3 to get transactions from a given version. Where the reply comes from is decided by one comparison against the durable version (the last confirmed cut): at or below it, the chunk range in object storage; above it, the buffer. The two regions always meet — buffered entries are only evicted once their chunk write confirms — so the stream is continuous from any starting position.

Every reply carries currency — %{high_water: v, kcv: k} — so an empty reply still means something: "nothing for you, but you are current through v" (FoundationDB's empty tag peek shape). Busy shards learn currency from slice pushes. Idle shards learn it by subscription, never by timer: parking a puller sends the Demux a one-shot currency request carrying what this shard has already seen; the Demux replies immediately if it knows more, and otherwise holds the interest and answers on its next push. The whole chain is event-driven — a reader is never waiting on a clock, only on messages that are already in flight.

Ownership

A ShardServer is anonymous and private to the process that starts it. In production that caller is one log replica's Demux, whose shard map is the only registry. start_link/1 records the actual caller as the owner, so durability and currency messages cannot be redirected through an option.