Architektur

Aufnehmen. Snapshot. Abspielen.

Ein Durable Object pro Workspace ist der einzige Writer; das macht Transaktionen serialisierbar ohne Lock-Manager. Das Log ist die Quelle der Wahrheit; Snapshots sind ein Checkpoint darüber, und das lokale Log wird auf dasselbe Fenster gekürzt, das R2 behält.

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

Committete Transaktionen gelangen ins lokale Log; der Flusher liefert Segmente nach R2, Snapshots checkpointen den State. Die Wiederherstellung baut aus dem Snapshot und den aufbewahrten Segmenten neu auf, inklusive Dateimetadaten und eines begrenzten Deduplizierungsfensters.

R2-Flushing ist asynchron. Ein erfolgreicher lokaler Schreibvorgang ist keine Aussage, dass die Bytes bereits in R2 angekommen sind. Der Release-Validierungsprozess muss den vollständigen Pfad write → flush → recovery durchlaufen.

Footprint

Der generierte Worker deklariert drei Ressourcen: eine Durable-Object-Klasse, den DATA-R2-Bucket (Log und Snapshots) und den FILES-R2-Bucket (Uploads). Es gibt kein D1. Mitgliedschaften und Sessions gehören zu deinem Identity-System; die Engine liest einen Header.

Request-Flow

HTTP-Requests tragen authentifizierte Queries und Schreibvorgänge zum Durable Object des Workspace. WebSocket-Subscriptions empfangen committete Änderungen und teilen sich die Verbindung mit Presence. Das Durable Object schreibt nach SQLite und ins Transaktionslog; sein Durability-Alarm liefert Logsegmente und Snapshots nach R2.