Daten-Vendor-Failover und Redundanz wenn der einzige Feed mitten im Handel ausfaellt.

Ein automatisiertes Trading-System ist nur so verlässlich wie der Datenstrom, von dem es lebt. Solange der eine Feed sauber läuft, denkt niemand darüber nach — bis er mitten im Handel ausfällt, einfriert oder, schlimmer noch, still Müll liefert. Im ersten Fall handelt das System blind, im zweiten handelt es auf falschen Annahmen weiter, und der zweite Fall ist der gefährlichere, weil er nicht sofort auffällt. Ein einzelner Datenanbieter ist damit ein klassischer Single Point of Failure: Geht er, geht alles. Redundanz mit automatischem Failover, Cross-Validierung mehrerer Quellen und sauberer Reconciliation macht den Feed nicht nur ausfallsicher, sondern auch ehrlicher — denn zwei Quellen, die sich widersprechen, decken Fehler auf, die eine einzelne nie zeigen würde. Dieser Beitrag erklärt, wie ein redundantes Feed-Setup aufgebaut wird, wie man saubere von verdorbenen Daten unterscheidet, was die Sache an Kosten und Komplexität mitbringt — und wo der Aufwand übertrieben wäre.

Der Single Point of Failure, den man gern verdrängt.

Solange ein Datenfeed zuverlässig läuft, ist er unsichtbar. Genau das macht ihn so trügerisch. Ein automatisiertes System verlässt sich auf einen kontinuierlichen, korrekten Strom von Kursen — und der einzelne Anbieter, der ihn liefert, ist eine Abhängigkeit, die man im Alltag schlicht vergisst. Bis zu dem Tag, an dem sie reißt.

Ausfälle kommen in mehreren Geschmacksrichtungen. Der harte Ausfall — der Feed bricht ab — ist noch der freundlichste, weil er sofort sichtbar ist. Tückischer ist der eingefrorene Feed, der weiter eine Verbindung hält, aber keine neuen Daten mehr schickt; das System sieht einen alten Kurs und hält ihn für aktuell. Am gefährlichsten ist der korrumpierte Feed, der weiterhin Daten liefert, aber falsche — ein verschobenes Dezimalkomma, ein Fehlprint, eine Lücke.

In allen drei Fällen handelt ein System, das nur eine Quelle kennt, auf einer falschen Realität. Es kann nicht erkennen, dass etwas nicht stimmt, weil es nichts hat, womit es vergleichen könnte. Genau diese fehlende Vergleichsmöglichkeit ist das Kernproblem.

Redundanz: mehr als nur ein zweiter Feed.

Die naheliegende Antwort — ein zweiter Anbieter — ist richtig, aber nur, wenn man sie konsequent denkt. Zwei Feeds desselben Aggregators, die unter der Haube dieselbe Ursprungsquelle nutzen, sind keine echte Redundanz: Fällt die gemeinsame Quelle aus, fallen beide. Echte Redundanz braucht unabhängige Wege — idealerweise unterschiedliche Anbieter mit unterschiedlicher Infrastruktur.

Man unterscheidet zwei Betriebsmodi. Im Aktiv-Passiv-Modell läuft ein Primärfeed, der Sekundärfeed ist warm bereit und übernimmt erst beim Ausfall. Das ist einfacher und günstiger. Im Aktiv-Aktiv-Modell laufen beide gleichzeitig, und das System vergleicht sie laufend. Das ist teurer und aufwendiger, hat aber einen entscheidenden Vorteil: Es erkennt nicht nur Ausfälle, sondern auch stille Korruption, weil ständig zwei Quellen gegeneinander geprüft werden.

Welches Modell passt, hängt vom Risiko ab. Für eine niederfrequente Strategie, die einen kurzen Ausfall verkraftet, reicht oft Aktiv-Passiv. Für ein latenz- und korrektheitskritisches System, bei dem ein falscher Kurs sofort teuer wird, lohnt der Mehraufwand von Aktiv-Aktiv.

Wie automatisches Failover funktioniert.

Failover ist die automatische Umschaltung von der ausgefallenen auf die gesunde Quelle, ohne dass ein Mensch eingreifen muss. Damit das sauber funktioniert, braucht es drei Dinge: ein verlässliches Kriterium, wann umgeschaltet wird, einen schnellen Umschaltvorgang, und einen ebenso definierten Rückweg.

Das Umschaltkriterium ist heikler, als es klingt. Schaltet man zu hektisch um — bei jeder einzelnen verspäteten Nachricht —, flattert das System zwischen den Quellen hin und her und schafft mehr Instabilität, als es verhindert. Schaltet man zu zögerlich, handelt man zu lange auf einem toten Feed. Bewährt hat sich, mehrere Signale zu kombinieren: Heartbeat-Ausfall, ausbleibende Updates über eine definierte Zeit, und Plausibilitätsverletzungen. Erst wenn diese zusammen ein klares Bild ergeben, wird umgeschaltet.

Genauso wichtig ist der Rückweg — der oft vergessene Teil. Wenn der Primärfeed sich erholt, sollte man nicht reflexartig sofort zurückspringen, sondern erst, wenn er nachweislich wieder stabil und konsistent liefert. Ein vorschnelles Zurückschalten auf eine Quelle, die noch wackelt, macht alles nur schlimmer.

Cross-Validierung: zwei Quellen, die sich kontrollieren.

Der eigentliche Mehrwert mehrerer Feeds liegt nicht nur in der Ausfallsicherheit, sondern darin, dass sie sich gegenseitig kontrollieren. Wenn zwei unabhängige Quellen denselben Kurs liefern, ist das Vertrauen hoch. Wenn sie auseinanderlaufen, ist das ein Alarm, den man mit einer einzelnen Quelle nie bekommen hätte.

In der Praxis vergleicht man die Quellen laufend auf Übereinstimmung — innerhalb einer Toleranz, denn kleine Abweichungen durch unterschiedliche Latenz oder Aggregation sind normal. Erst wenn die Differenz eine sinnvoll gesetzte Schwelle überschreitet, schlägt das System Alarm. Dann stellt sich die schwierige Frage: Welche Quelle hat recht?

Hier hilft eine klare Logik. Bei zwei Quellen kann man nicht abstimmen — man braucht eine vorab definierte Vertrauensrangfolge oder Plausibilitätsregeln, die entscheiden, welche Quelle im Konfliktfall gilt. Mit drei Quellen wird es robuster, weil man nach Mehrheit entscheiden kann: Stimmen zwei überein und eine weicht ab, ist die abweichende verdächtig. Drei Quellen kosten mehr, lösen aber das Schiedsrichter-Problem eleganter.

Reconciliation: Abweichungen sauber auflösen.

Cross-Validierung erkennt Abweichungen — Reconciliation klärt sie auf und sorgt dafür, dass am Ende ein konsistenter Datenstand übrig bleibt. Ohne diesen Schritt sammelt man nur Widersprüche, ohne sie aufzulösen.

Ein praktikabler Ablauf umfasst mehrere Stufen:

• Erkennen: Differenzen zwischen den Quellen über eine Toleranz hinaus markieren und protokollieren.
• Einordnen: Unterscheiden, ob die Abweichung harmlos ist (Latenz, Rundung) oder substanziell (Fehlprint, Lücke, Dezimalfehler).
• Entscheiden: Nach Vertrauensrangfolge oder Mehrheit festlegen, welcher Wert als gültig gilt.
• Dokumentieren: Jede aufgelöste Abweichung festhalten — diese Protokolle sind später Gold wert, um systematische Schwächen eines Anbieters zu erkennen.

Wichtig ist die Trennung zwischen Echtzeit-Reconciliation (schnell, für Live-Entscheidungen, mit einfacher Logik) und nachgelagerter Reconciliation (gründlich, für die Datenhistorie und Backtests). Beide haben ihren Platz, dürfen aber nicht verwechselt werden — die Live-Logik muss schnell und einfach sein, die historische darf gründlich und langsam sein.

Was Redundanz kostet — und was ein Ausfall kostet.

Redundanz ist nicht umsonst. Ein zweiter, unabhängiger Datenanbieter bedeutet doppelte Lizenzkosten, zusätzliche Anbindungsarbeit und eine spürbar komplexere Architektur, die selbst gewartet werden will. Diese Kosten sind real und laufen monatlich weiter, auch wenn der Primärfeed jahrelang nie ausfällt.

Dem steht der Schaden eines Ausfalls gegenüber, und der ist asymmetrisch. Ein paar Minuten blinder Handel in einem ruhigen Markt kosten vielleicht wenig. Dieselben Minuten in einem volatilen Moment — und Ausfälle häufen sich erfahrungsgemäß genau dann, wenn die Last hoch ist — können ein Vielfaches der jährlichen Redundanzkosten vernichten. Die Versicherung ist gerade dann am wertvollsten, wenn man sie am dringendsten braucht.

Die ehrliche Abwägung hängt davon ab, wie viel ein Fehlhandeln in der schlimmsten Stunde kosten würde, nicht im Durchschnitt. Für ein kleines, niederfrequentes System mit engen Risikolimits mag ein einzelner, sorgfältig überwachter Feed mit klaren Stopp-Regeln genügen. Für ein größeres, automatisiertes System, das bei einem falschen Kurs sofort und gehebelt handelt, ist Redundanz keine Luxusfrage, sondern Grundausstattung.

Ein pragmatischer Einstieg und ehrliche Grenzen.

Man muss nicht sofort ein Drei-Quellen-Aktiv-Aktiv-System bauen. Ein sinnvoller erster Schritt ist oft günstiger und wirkungsvoller als gedacht: Schon ein zweiter, auch einfacherer Feed allein zur Cross-Validierung — der gar nicht primär handelt, sondern nur den Hauptfeed kontrolliert — fängt einen großen Teil der stillen Korruption ab. Das ist deutlich billiger als volle Aktiv-Aktiv-Redundanz und liefert den größten Teil des Sicherheitsgewinns.

Parallel dazu gehören klare Notfallregeln: Was tut das System, wenn alle Quellen widersprechen oder ausfallen? Die sicherste Antwort ist meist, in den Risk-Off-Modus zu gehen — bestehende Positionen schützen, keine neuen eröffnen — statt auf unsicherer Datenbasis weiterzuhandeln. Nicht handeln ist im Zweifel die bessere Entscheidung als blind handeln.

Und die Grenzen: Redundanz schützt vor Ausfall und Korruption einzelner Quellen, nicht vor einem marktweiten Datenproblem, das alle Anbieter gleichzeitig trifft — etwa eine fehlerhafte Börsenmeldung an der Quelle. Auch erkauft man Sicherheit mit Komplexität, und Komplexität ist selbst eine Fehlerquelle. Ein redundantes System, das niemand mehr versteht, ist nicht sicherer, sondern nur undurchsichtiger. Die Kunst ist, so viel Redundanz zu bauen, wie das Risiko verlangt — und nicht mehr.

Sie hängen mit Ihrem automatisierten System an einem einzigen Datenanbieter und fragen sich, was bei einem Ausfall passiert? Unverbindlich anfragen — wir bewerten gemeinsam Ihr Ausfallrisiko, schätzen den Schaden eines Feed-Ausfalls in der schlimmsten Stunde realistisch ab und legen ein Redundanz-Niveau fest, das zu Ihrem System passt.