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.

R2-flushing is asynchroon. Een geslaagde lokale schrijfactie is geen claim dat de bytes al in R2 staan. Het releasevalidatieproces moet het volledige pad write → flush → recovery doorlopen.

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.