FORSCHUNG UND PRAXIS

Datenqualität bei Krypto-WebSockets: Lücken, Reihenfolge und sichere Wiederherstellung

Eine praktische Prüfliste für Kryptomarktdaten: Sequenzlücken, doppelte Updates, veraltete Momentaufnahmen und Wiederherstellung vor der Fortsetzung von Signalen.

Redaktionelle Illustration zum Thema: Datenqualität bei Krypto-WebSockets: Lücken, Reihenfolge und sichere Wiederherstellung
Redaktionelle Illustration; keine Live-Marktdaten. Photo: Jakub Zerdzicki · Pexels

Eine bestehende WebSocket-Verbindung ist noch keine verlässliche Marktansicht. Nachrichten können verspätet eintreffen, die lokale Verarbeitung kann zurückfallen und ein Orderbuch kann sichtbar bleiben, obwohl der für seine Aktualisierung erforderliche Zustand verloren ging. Entscheidend ist, ob sich die aktuelle Darstellung aus einem gültigen Ausgangspunkt und den erforderlichen Updates rekonstruieren lässt. Eine Qualitätsprüfung sollte diese Frage beantworten, bevor ein Modell die Zahlen interpretiert.

01

Jeder Beobachtung eine Identität geben

Bewahre Handelsplatz, Produkt, Kanal, Ereigniskennung oder dokumentierte Sequenz, Ereigniszeit und lokale Empfangszeit auf. Sequenzregeln gelten kanalspezifisch: Ein bei einem Datenstrom lückenloser Zähler muss bei einer gefilterten Teilmenge eines anderen Stroms nicht lückenlos sein. Die Börsendokumentation von Coinbase behandelt ausdrücklich Lücken und eine veränderte Zustellreihenfolge. Deshalb braucht ein Datenempfänger mehr als ein Verbindungsstatussymbol. Halte Analysefehler und nicht unterstützte Nachrichtentypen in der Diagnose sichtbar. Fehlerhafte Felder stillschweigend in Null umzuwandeln, kann ein nie eingetretenes Marktereignis erzeugen, das schwerer erkennbar ist als ein ausdrücklich fehlender Wert.

02

Von einer konsistenten Momentaufnahmegrenze aus neu aufbauen

Ein Orderbuch benötigt normalerweise eine Momentaufnahme sowie die Updates nach deren Grenze entsprechend dem Protokoll des gewählten Feeds. Regeln für Zwischenspeicherung, Reihenfolge und Wiederholung müssen diesem Protokoll entnommen werden, statt sie aus Beispielen einer anderen Börse abzuleiten. Behandle eine neue Momentaufnahme als Ersatzzustand, wenn die Dokumentation dies vorsieht. Werden ihre Stufen mit einem älteren lokalen Orderbuch vermischt, können bereits verschwundene Orders erhalten bleiben. Dokumentiere die Wiederherstellungsgrenze und den frühesten Zeitpunkt, ab dem abgeleitete Indikatoren wieder gültig sind; die erneute Socketverbindung allein beweist keine Kontinuität.

03

Ein hypothetisches fehlendes Update

Stelle dir einen Kanal mit dokumentierter lückenloser Sequenz vor: Auf einen gültigen Zustand bei 100 folgen die Updates 101 und 103. Update 102 könnte die Stornierung des besten Kaufgebots enthalten. Direkt mit 103 fortzufahren könnte deshalb Kaufunterstützung überzeichnen, selbst wenn jeder empfangene Preis plausibel aussieht. Markiere davon abhängige Orderbuchmerkmale als nicht verfügbar, starte die dokumentierte Neusynchronisierung und fahre erst fort, wenn der neue Zustand konsistent ist. Füge für 102 kein erfundenes leeres Update ein. Zähle ebenso wenig ein erneut übertragenes 101 doppelt: Die Duplikatbehandlung muss den Zustand einer einmaligen korrekten Anwendung bewahren.

04

Aktualität und Verarbeitungsrückstand getrennt messen

Das Ereignisalter schätzt das Alter der zugrunde liegenden Marktinformation, während die lokale Verarbeitungsverzögerung zeigt, ob der Empfänger zurückfällt. Ein Heartbeat kann eine lebende Verbindung anzeigen, ohne aktuelle Orderbücher oder Handelsströme aller Produkte zu beweisen. Vergleiche Zeitstempel erst nach Prüfung ihrer Einheiten und Zeitannahmen; mit Millisekunden verwechselte Sekunden können eine scheinbar strenge Altersgrenze aushebeln. Nutze für lokal verstrichene Zeiten möglichst eine monotone Uhr. Bewahre produktbezogene Alterswerte und Warteschlangentiefe auf, statt einen globalen Zeitstempel zu verwenden, den ein anderes aktives Instrument auffrischen kann.

05

Die Wiederherstellung mit erklärbaren Fehlern testen

Spiele einen aufgezeichneten Abschnitt erneut ab, nachdem du gezielt ein Update entfernt, einen Trade dupliziert, die Ankunftsreihenfolge verändert oder die Verbindung unterbrochen hast. Die erwartete Reaktion muss je Kanal feststehen. Prüfe, ob eine Lücke einen zurückgehaltenen Indikator statt einer starken Kauf- oder Verkaufsanzeige erzeugt und ob die Wiederherstellung dieselben Trades nicht zweimal in kumulative Kennzahlen einspielt. Vergleiche den rekonstruierten Zustand mit einer neuen vertrauenswürdigen Momentaufnahme, soweit das Protokoll dies erlaubt. Beziehe ruhige Märkte ein: Fehlende Trades können legitim sein, während ein veraltetes Orderbuch nicht allein durch geringe Aktivität gesund werden darf.

06

Unsicherheit für die Entscheidungsebene sichtbar machen

Veröffentliche neben abgeleiteten Kennzahlen einen kompakten Qualitätszustand: aktuell, in Wiederherstellung, veraltet oder nicht verfügbar, gegebenenfalls mit Alter und Begründung. Bewahre den letzten gültigen Wert nur dann zur Diagnose auf, wenn er klar gekennzeichnet ist; lasse ihn nicht als vermeintlich neue Beobachtung in eine aktuelle Rangliste eingehen. Prüfe den nutzbaren Zeitanteil jedes Markts und ob sich Ausfälle in volatilen Phasen häufen. Ein Scanner, der wegen fehlender Daten weniger Kandidaten meldet, verhält sich anders als einer, der das gesamte Universum geprüft und keine Kandidaten gefunden hat. Eine ehrliche Abdeckungsangabe macht diesen Unterschied sichtbar.

Quellen und Einordnung der Beispiele

Die Quellen belegen Definitionen und Mechanismen. Die Zahlenbeispiele sind hypothetische Lernbeispiele, keine aktuellen Kurse, Prognosen oder berichteten HOSTuvo-Ergebnisse. Bilder dienen der redaktionellen Illustration.