Architecture

Record. Snapshot. Replay.

One Durable Object per workspace is the only writer, which is what makes transactions serializable without a lock manager. The log is the source of truth; snapshots are a checkpoint over it, and the local log is trimmed to the same window R2 keeps.

client ──HTTP /transact──▶ Worker ──claim──▶ WorkspaceRoom (SQLite)
   ▲                                             │
   └──WebSocket subscribe / presence ◀───────────┘
                                                 │
                                          R2 DATA (log + snapshots)

Committed transactions enter the local log; the flusher ships segments to R2, and snapshots checkpoint state. Recovery rebuilds from the snapshot and retained segments, including file metadata and a bounded deduplication window.

R2 flushing is asynchronous. A successful local write is not a claim that its bytes have already reached R2. The release validation process must exercise the complete write → flush → recovery path.

Footprint

The generated Worker declares three resources: one Durable Object class, the DATA R2 bucket (log and snapshots), and the FILES R2 bucket (uploads). There is no D1. Memberships and sessions belong to your identity system; the engine reads one header.

Request flow

HTTP requests carry authenticated queries and writes to the workspace’s Durable Object. WebSocket subscriptions receive committed changes and share the connection with presence. The Durable Object writes to SQLite and the transaction log; its durability alarm ships log segments and snapshots to R2.