TARDIS Consistency

Ein exotisches, modernes Konsistenzmodell für Systeme, die offline-first sind oder extrem schwache Netzwerke haben (IoT, Mobile). Normalerweise: Wenn Datenkonflikte auftreten (A schreibt X, B schreibt Y), muss man sie sofort lösen (Merge) oder einen Gewinner wählen. TARDIS erlaubt "Time Travel". Man kann Zustände aus verschiedenen Zweigen der Historie lesen. Wenn ein Konflikt auftritt, spaltet sich die Realität (wie in Sci-Fi). Das System erlaubt es Applikationen, diese Zweige explizit zu "mergen", wenn wieder Verbindung besteht. Es ist flexibler als Causal Consistency, weil es Konflikte länger toleriert und intelligenter löst. Benannt nach der Zeitmaschine aus "Doctor Who".

Merksatz: Ein Konsistenzmodell für verteilte Speicher, das Clients erlaubt, auf verschiedenen "Zeitlinien" (Versionen) zu arbeiten und diese später rekursiv zusammenzuführen (Merge), optimiert für schwache Konnektivität.

Noch kaum in Mainstream-DBs. Aber Konzepte finden sich in:

Git: Branching und Merging ist TARDIS-Logik für Code.
Local-First Software: (Automerge, Yjs). Hier darf jeder offline arbeiten. Der "Merge" passiert später. TARDIS formalisiert das für Datenbanken.

1. Branch-and-Merge

Statt einer linearen History (Log) hat man einen DAG (Directed Acyclic Graph) von Versionen. Ein Read kann spezifizieren: "Gib mir den Zustand am Ende von Branch A". Ein Merge-Node führt A und B zusammen.

2. Drei Regeln

Read-Monotonicity: Innerhalb eines Branches geht es vorwärts.
Branch-Preservation: Alte Versionen bleiben erhalten (für Time Travel).
Convergence: Irgendwann kann alles zu einem Pfad zusammengeführt werden.

1. Branching Timelines & Logical Clocks

In TARDIS wird jeder Branch durch eine Logical Clock (wie Lamport Clocks oder Vector Clocks) oder einen Content-Hash identifiziert. Wenn du liest, entscheidest du: "Ich will die Daten von Replica A sehen, so wie sie vor seinem letzten Offline-Gang waren." Das System verwaltet intern einen Version Graph. In der Forschung (z.B. am MIT) nutzt man dies für "Probabilistische Datenbanken": Man behält mehrere Möglichkeiten der Wahrheit gleichzeitig im System, bis genug Daten da sind, um den "richtigen" Pfad auszuwählen (Collapse the Wavefunction).

2. Reconciliation Policies (Custom Merge)

Das Schwierigste ist der Merge. TARDIS bietet APIs für Reconciliation Policies.

Syntactical Merge: JSON-Merging (z.B. beide Felder behalten).
Semantic Merge: Die Applikationslogik entscheidet. Beispiel E-Commerce: Wenn zwei Leute gleichzeitig das letzte Produkt kaufen (offline), entscheidet der Merge beim Online-Gehen: "Wer war zuerst da (Timestamps)?" oder "Generiere eine Alarm-Email für den Support." In TARDIS ist dies kein Bug, sondern ein geplanter Workflow-Schritt in der Daten-Evolution.

3. Partial Order & Happens-Before

TARDIS basiert mathematisch auf der Partial Order von Events. Zwei Events sind unvergleichbar, wenn sie in verschiedenen Zweigen passierten. Das System erzwingt keine totale Ordnung, solange es nicht nötig ist. Das reduziert die Latenz auf nahezu Null, da kein Knoten auf eine globale Einigung (Paxox/Raft) warten muss. Die Konsistenz wird von der "Laufzeit" (Runtime) auf den "Merge-Zeitpunkt" verschoben. Dies ist ideal für Edge-Computing, wo Geräte oft Wochen ohne Verbindung in der Wüste oder auf hoher See verbringen.