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. Die Wiederherstellung läuft in Schritten, die ihren Fortschritt festschreiben, einen Snapshot-Chunk oder ein Logsegment nach dem anderen. So wird ein Workspace jeder Größe wiederhergestellt, und eine unterbrochene Wiederherstellung macht dort weiter, wo sie war. Bis sie fertig ist, antwortet der Workspace mit 503 workspace_recovering und Retry-After, nie mit einem halben Ergebnis.

R2-Flushing ist asynchron. Ein erfolgreicher lokaler Schreibvorgang ist keine Aussage, dass die Bytes bereits in R2 angekommen sind.

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.