Cloud-Synchronisierung für Nutzerdaten ist mehr als Hoch- und Herunterladen. Sie muss private Inhalte bei der Übertragung schützen, Speicherkosten niedrig halten, Schreibvorgänge mehrerer Geräte serialisieren, unterschiedliche Datenstrukturen verstehen, vor riskanten Löschungen eine Bestätigung einholen und einen Rückweg erhalten, wenn sich eine Entscheidung als falsch erweist.
Orkas behandelt Cloud-Synchronisierung als Produktgrenze, nicht als Hintergrundwerkzeug. Gespräche, Agenten, Skills, Aufgabenstatus, Wissensdateien und Einstellungen müssen zwischen Geräten übertragen werden, bei klaren Zuständigkeiten: Das Gerät bereitet Inhalte vor, der Objektspeicher hält die Bytes und der Server verwaltet den maßgeblichen Index.
Das folgende Rahmenmodell verwenden wir, um das System zu durchdenken: verschlüsselter Inhaltsfluss, inhaltsadressierter Speicher, Synchronisierungssperre auf Kontoebene, serverseitig verantworteter Commit, deterministische Synchronisierungsregeln, modellgestützte Konfliktbehandlung, Löschbestätigung, Papierkorb und Wiederherstellungsmarkierungen.
Der Synchronisierungsvertrag
Jeder Synchronisierungslauf beantwortet vier Produktfragen: Welche Inhalte dürfen übertragen werden, wie werden sie geschützt, wer darf einen neuen Cloud-Index veröffentlichen und wie kann der Nutzer Daten wiederherstellen, wenn die Synchronisierung falsch entschieden hat?
Verschlüsselter Inhaltsweg
Nutzerdaten werden auf dem Gerät vorbereitet, bevor sie den Speicher erreichen. Die Synchronisierungsengine normalisiert die Kandidatenmenge, berechnet die Inhaltsidentität, verschlüsselt die Nutzdaten, lädt sie mit kurzlebigen Zugangsdaten hoch und prüft heruntergeladene Bytes, bevor sie sie auf das Gerät zurückschreibt.
Speicher und Index
Orkas trennt gespeicherte Bytes vom Cloud-Index. Inhaltsobjekte enthalten die verschlüsselten Daten. Der Index erfasst, welche logischen Datenelemente vorhanden sein sollen, ihre Inhaltsidentität, Versionszähler, gespeicherte Größe, Cloud-Revision und ihren Löschmarkierungsstatus. Das Gerät bewahrt außerdem einen Ausgangsstand des letzten erfolgreichen Laufs auf, um alten Zustand von neuen Änderungen unterscheiden zu können.
Ein Synchronisierungslauf
Ein Lauf beginnt kostengünstig und wird erst streng, wenn tatsächlich Arbeit anfällt. Orkas prüft zunächst, ob sich etwas geändert hat, erwirbt dann die Synchronisierungssperre des Kontos, berechnet Änderungen unter dieser Sperre neu, überträgt Inhalte, bittet den Server um einen Commit der Indexoperationen und aktualisiert abschließend den Geräteausgangsstand.
Synchronisierungssperre und Commit
Synchronisierungssperre und Commit-Prüfung lösen unterschiedliche Probleme. Die Synchronisierungssperre reduziert unnötige parallele Arbeit mehrerer Geräte. Die serverseitige Sperre serialisiert Schreibvorgänge am Index. Die Prüfung der erwarteten Cloud-Revision verhindert, dass ein älterer gelesener Stand zur nächsten Wahrheit wird. Kontingent- und Schemaprüfungen laufen im selben serverseitig verantworteten Commit-Pfad.
Regeln vor Konflikten
Die meisten Synchronisierungsentscheidungen sind keine Konflikte. Das Gerät vergleicht den Ausgangsstand, die aktuellen Gerätedaten und den Cloud-Index. Hat sich nur die Cloud geändert, wird abgerufen. Hat sich nur das Gerät geändert, wird hochgeladen. Haben sich beide geändert, entscheidet der Inhaltstyp über das Vorgehen. Ist etwas verschwunden, beginnt der sichere Löschpfad, statt sofort Daten zu entfernen.
Konfliktbehandlung
Wenn sich tatsächlich beide Seiten geändert haben, reduziert Orkas nicht alles auf „der letzte Schreibvorgang gewinnt“. Fortlaufende Protokolle lassen sich durch Ergänzen fehlender Datensätze zusammenführen. Listen können anhand stabiler Datensatzidentitäten zusammengeführt werden. Strukturiertes JSON kann Versionszähler und Zeitstempel nutzen. Bei Markdown und Binärdateien geht das System vorsichtig vor: Kann es eine verlustfreie Zusammenführung nicht nachweisen, behält es eine vollständige Kopie der unterlegenen Version.
Bei mehrdeutigen Konflikten in Texten oder strukturierten Inhalten kann das Produkt die relevanten Versionen für eine modellgestützte Behandlung bündeln. Das Modell kann den Konflikt erklären, eine zusammengeführte Version entwerfen oder dem Nutzer bei der Auswahl helfen. Es ist nicht der einzige Schutzmechanismus: Deterministische Validierung, archivierte Originale und für den Nutzer sichtbare Wiederherstellung bleiben Teil des Ablaufs.
Löschbestätigung
Löschungen werden als Zustandsübergänge behandelt. Eine entfernte Löschung wird zur Löschmarkierung. Eine geräteseitige Löschung wird zu einer möglichen Operation. Orkas prüft kürzliche Schreibvorgänge, achtet auf große Löschwellen und pausiert den Lauf zur Bestätigung, wenn die Menge verschwindender Nutzerdaten riskant erscheint.
Papierkorb und Wiederherstellung
Bevor eine gültige Löschung eine Gerätekopie entfernt, verschiebt Orkas sie in den Synchronisierungspapierkorb. Unterlegene Konfliktversionen werden zur Prüfung archiviert. Ausstehende Uploads überstehen einen fehlgeschlagenen Commit, damit der nächste Lauf die Bytes wiederverwenden kann. Wenn ein Nutzer Cloud-Daten bewusst löscht, sehen andere Geräte eine Bereinigungsmarkierung und laden veraltete Inhalte nicht erneut hoch.
Was uns das bringt
Das Ergebnis ist ein Synchronisierungssystem mit klaren Grenzen. Geräte bereiten Inhalte vor und prüfen sie. Der Objektspeicher hält verschlüsselte Bytes. Der Server veröffentlicht den Index. Die Synchronisierungssperre des Kontos und die Serversperre halten die Läufe geordnet. Regeln behandeln die üblichen Fälle. Modellunterstützung hilft bei mehrdeutigen Konflikten. Löschbestätigung und Papierkorb schützen Nutzer vor den teuersten Fehlern.
Das ist der Maßstab, den Orkas für Cloud-Synchronisierung braucht: keine Magie, keine blinde Spiegelung, sondern ein sorgfältiger Mechanismus, mit dem Nutzerdaten zwischen Geräten wandern und sich dennoch konsistent anfühlen.