Architectuur

Opnemen. Snapshot. Terugspelen.

Eén Durable Object per workspace is de enige schrijver; daardoor zijn transacties serialiseerbaar zonder lockmanager. Het log is de bron van waarheid; snapshots zijn een checkpoint eroverheen, en het lokale log wordt bijgehouden tot hetzelfde venster dat R2 bewaart.

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

Gecommitte transacties komen in het lokale log; de flusher verstuurt segmenten naar R2 en snapshots checkpointen de state. Herstel bouwt opnieuw op uit het snapshot en de bewaarde segmenten, inclusief bestandsmetadata en een begrensd deduplicatievenster. Herstel loopt in stappen die hun voortgang vastleggen, een snapshot-chunk of logsegment tegelijk, dus een workspace van elke grootte herstelt en een onderbroken herstel gaat verder waar het was. Tot het klaar is antwoordt de workspace met 503 workspace_recovering en Retry-After, nooit met een half resultaat.

R2-flushing is asynchroon. Een geslaagde lokale schrijfactie is geen claim dat de bytes al in R2 staan.

Voetafdruk

De gegenereerde Worker declareert drie resources: één Durable Object-klasse, de DATA R2-bucket (log en snapshots) en de FILES R2-bucket (uploads). Er is geen D1. Lidmaatschappen en sessies horen bij je identity-systeem; de engine leest één header.

Requestflow

HTTP-verzoeken dragen geauthenticeerde queries en schrijfacties naar de Durable Object van de workspace. WebSocket-subscriptions ontvangen gecommitte wijzigingen en delen de verbinding met presence. De Durable Object schrijft naar SQLite en het transactielog; zijn durability-alarm verstuurt logsegmenten en snapshots naar R2.