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. Recovery runs in steps that commit their progress, a snapshot chunk or log segment at a time, so a workspace of any size recovers and a recovery cut off by a restart resumes. Until it is complete the workspace answers 503 workspace_recovering with Retry-After, never a partial result.

R2 flushing is asynchronous. A successful local write is not a claim that its bytes have already reached R2.

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.