A database is not one design. Pick the application it is for, and the engine below reconfigures — strategy, seal policy, WebSocket mode — then watch a write go through it.
Simulated, and proposing rather than describing. This models the design in ARCHITECTURE.md §12, not what ships today: DO storage as a write-ahead log, R2 as the read layer, no KV. It runs the engine's own revision hash (verified byte-for-byte against a running Worker), key formats and stored shapes. Nothing is sent anywhere. Bytes and operation counts are exact; latency is not modelled.
Each row is a strategy and its parameters. Today an operator picks; the intent is that a customer declares the intent and the platform picks, per database.
Browsers — a full local copy each
The writer. A save lands here first with pending: true, a provisional
revision and seq: -1 — which is what makes the UI instant and offline
capable. The schema is docs: 'id, seq'; booleans cannot be indexed, so
pending is a full scan.
store …
The reader. meta.checkpoint is the whole sync protocol on this side: pull
everything past it, apply oldest-first so the highest seq wins, move it to
the server's live seq.
store …
In between — holds nothing, decides nothing
Resolves the tenant from the verified credential — never from the URL or the body —
picks the room by idFromName("{tenant}:{db}") and forwards. It stores
nothing between requests, which is why this panel is empty whenever nothing is in
flight.
room …
Two classes of traffic, counted apart on purpose. Write frames are sent before the push is answered; what they carry is the strategy's decision, not a setting. Ephemeral frames — cursors, presence, typing — are broadcast and dropped: no seq, no tail entry, no storage row, no segment, no R2 operation. That is the only mechanism here that removes load rather than moving it.
…
Stores — where a document actually lives
The single writer, and the reason seq is a total order. The tail is a Map
keyed by document id, so a second write to one document replaces its entry rather than
adding one — which is why a database with 200k writes can hold a tail of a few thousand.
Its documented soft limit is 1,000 requests per second, so who lands here is
the design question this page is about.
seq 0 · tail 0 / 5
Local to the machine and measured at 0ms, which is what lets it confirm the push and
leave the R2 write off the critical path. One row per document — doc:{id}
for the label, tail:{id} for the unsealed entry — so the 2 MB per-value cap
applies to a pair of a few dozen bytes and never binds. The earlier design kept these as
one key each and hit 128% of that cap at 81,310 documents.
Strongly consistent: a put is visible globally, immediately. The object being written is
the segment in progress — sealing stops writing that key and opens the next one,
so the same bytes that served reads a moment ago become the sealed segment. Nothing is
copied and nothing is renamed, which is why a segment is named by its
from_seq alone.
…