Zwei Oberflächen. Eine Handelsentscheidung.
Eine Quant-Trading-Firma hatte eine reale, aber banale Frustration: Die Daten, die sie für eine einzige Entscheidung brauchte, lagen in zwei getrennten Tools, die voneinander nichts wussten.
Auf der einen Seite ein Earnings-Kalender. Vier große öffentlich zugängliche Quellen, jede leicht unterschiedlich — andere Symbole, andere Konventionen für die Anrufzeit, gelegentliche Duplikate, gelegentliche Widersprüche. Das Team glich sie von Hand ab, bevor irgendetwas gehandelt wurde.
Auf der anderen Seite das SPX-Dealer-Gamma-Exposure. Der Optionsmarktstruktur-Indikator, der einem sagt, wo sich systematischer Hedging-Druck konzentriert — welche Strikes magnetisch werden, wenn sich der Markt auf sie zubewegt, wo Dealer Schwäche kaufen und Stärke verkaufen, wie viel Puffer der Index hat, bevor mechanisches Verkaufen einsetzt. Es gibt kein Bloomberg-Feld dafür. Man leitet es ab. Frisch, aus der Optionskette der Börse, mit pro Strike berechnetem Black-Scholes-Gamma und nach Delta-Anpassung aggregiert. Und man tut das alle fünfzehn Minuten während der Cash-Session, sonst ist die Zahl, die man hat, bereits falsch.
Das Briefing war spezifisch: ein Bildschirm, beide Signale, synchronisiert. Über ein Earnings-Ereignis fahren. Das Gamma-Bild für dieses Datum sehen. Fertige Produkte können das eine oder das andere. Niemand machte beides in einer einzigen Ansicht.
Eine verschmolzene Ansicht: Ereigniskalender oben, Gamma-Exposure darunter.
Das Dashboard gab den Tradern der Firma einen Earnings-Kalender, der Symbole aus vier unabhängigen Datenquellen zutage förderte — dedupliziert, abgeglichen, mit Anrufzeit-Indikatoren — über einem Live-Gamma-Exposure-Chart für SPX. Die beiden Oberflächen waren synchronisiert: über ein Earnings-Datum fahren, und der Gamma-Chart sprang zum Exposure-Bild für diese Session.
Der Gamma-Chart zeigte das aggregierte Dealer-Exposure pro Strike, delta-angepasst, mit einer Netto-Gamma-Linie, die den Wechsel zwischen positiv und negativ auf einen Blick sichtbar machte. Zero-Gamma — der Punkt, an dem das Dealer-Hedging von stabilisierend zu verstärkend kippt — war als Konstante markiert. Die Tageseröffnung und der Vortagesschluss waren Referenzlinien. Strike-Cluster, an denen sich das Exposure konzentrierte, zeigten sich als Spitzen.
Der Earnings-Kalender zeigte bestätigte und vorläufige Ereignisse mit Anrufzeit-Indikatoren (BMO, AMC, unbestätigt). Symbol-Level-Filterung, ein Datumsbereichsselektor und eine Watchlist-Ansicht ließen einen Trader den Kalender auf sein Buch eingrenzen, ohne die Gamma-Schicht zu berühren. Die beiden Ansichten teilten dieselbe Datumsachse. Das war der ganze Sinn.
Das Frontend lief auf Next.js 16 und React 19, wobei D3.js das Gamma-Rendering übernahm und Zustand den gemeinsamen Kalender-/Chart-Status verwaltete. Vercel Analytics war ab der ersten Produktionswoche verdrahtet.
- F · 01Mehrquellen-Earnings-Kalender
- Vier unabhängige Quellen, dedupliziert nach Symbol, Datum und Anrufzeit. Retry-and-Backoff-Handling pro Quelle degradiert den Kalender sanft, wenn eine Quelle bricht — die Ansicht des Traders wird nie dunkel.
- F · 02Live-SPX-Gamma-Exposure-Chart
- Black-Scholes-Gamma frisch berechnet auf der vollständigen SPX-Optionskette, alle fünfzehn Minuten während der Handelszeiten. Nach Strike aggregiert, delta-angepasst. Zero-Gamma und wichtige Referenzlinien markiert.
- F · 03Synchronisierte Datumsachse
- Über ein Earnings-Ereignis fahren, und der Gamma-Chart springt zum Exposure-Bild für diese Session. Die Fusion liegt in der Interaktion, nicht nur im Layout.
- F · 04Reiner Redis-Hot-Store
- Keine kalte Datenbank. Beide Pipelines schreiben in Redis JSON, indiziert nach Datum und Symbol. Sub-Millisekunden-Lesezugriffe im Frontend. Das Zugriffsmuster brauchte nie mehr.
- F · 05Telemetrie pro Quelle
- Jeder Earnings-Parser legt seinen Retry-Status als Metrik offen. Ein defekter Parser taucht innerhalb eines Aktualisierungszyklus im Monitoring-Dashboard auf — bevor jemand, der gegen die Daten handelt, es bemerkt.
- F · 06Zwei-Sprachen-Backend
- Node/Express für Scraping und Deduplizierung. Python/FastAPI für die Quant-Schicht — scipy.stats, numpy, pandas. Jede Sprache besitzt das Problem, zu dem sie passt. Ein Cache hält das Ergebnis.
Ein Cache, zwei Pipelines, zwei Sprachen.
Das Datenfusionsproblem unter dem Dashboard war eine Architekturentscheidung mit einer klaren Antwort: zwei unabhängige Pipelines, keine blockiert die andere, beide schreiben in einen einzigen Hot Store.
Die Earnings-Pipeline lief in Node und Express. Ein Scraper-Dienst zog alle drei Stunden von vier unabhängigen öffentlich zugänglichen Kalendern. Jede Quelle hatte ihren eigenen Parser — isoliert, mit Retry-and-Backoff-Handling, sodass ein vorübergehender Ausfall einer Quelle die anderen nicht beschädigte. Die Deduplizierung lief nach Symbol plus Datum plus Anrufzeit; ein Symbol, das in drei Quellen mit geringfügigen Unterschieden in der Datumsformatierung auftauchte, löste sich zu einem kanonischen Datensatz auf. Telemetrie pro Quelle bedeutete, dass ein defekter Parser im Monitoring-Dashboard sichtbar war, bevor ein Trader etwas falsch laufen sah.
Die Gamma-Pipeline lief in Python. FastAPI bediente die Quant-Schicht: eine frische SPX-Optionskette, alle fünfzehn Minuten während der Handelszeiten aus dem CSV-Feed der Börse gezogen, durch eine Black-Scholes-Gamma-Berechnung mit scipy.stats und numpy geleitet, nach Strike aggregiert und delta-angepasst. Python war hier das richtige Werkzeug — scipy.stats, das wissenschaftliche Python-Ökosystem und die Art, wie das Quant-Team ohnehin über die Berechnung nachdachte. Eine Neufassung in TypeScript hätte Reibung ohne jeden Vorteil hinzugefügt.
Sobald es keine kalte Datenbank gab, auf die man zurückfallen konnte, musste jede Pipeline beim Schreiben korrekt sein. Dieser Druck brachte sauberere Parser und eine schärfere Bereitschaftsgeschichte hervor.
Beide Pipelines schrieben in Redis. Keine kalte Datenbank — bewusst so, nicht aus Versehen. Telemetrie aus den ersten Produktionswochen bestätigte, was die Architektur annahm: Das Zugriffsmuster war immer „Wie sieht das Bild gerade jetzt aus“, nie „Wie sah es vor sechs Wochen aus“. Redis JSON, indiziert nach Datum und Symbol, gab dem Frontend Sub-Millisekunden-Lesezugriffe auf den aktuellen Status. Der Cache war der gesamte Speicher.
Vier Jahre in Produktion. Aktualisiert noch immer alle fünfzehn Minuten.
Das Dashboard ging 2022 zum ersten Mal in Produktion und läuft seither durchgehend. Die Zwei-Pipeline-Architektur hat drei Jahre Selektor-Wechsel auf den Earnings-Quellen, Formatänderungen des Börsen-Feeds auf der Gamma-Seite und einen vollständigen Frontend-Neubau überstanden, als die React-19-Migration anstand.
Die Earnings-Abdeckung liegt bei über 5.000 Symbolen über vier unabhängige Quellen. Die Gamma-Engine verarbeitet über 3.000 SPX-Strikes pro Verfallszyklus. Die Aktualisierungstakte haben sich nicht geändert: Earnings alle drei Stunden, Gamma alle fünfzehn Minuten während der Cash-Session.
Die Circuit-Breaker-Telemetrie pro Quelle war das operativ nützlichste Feature. Quell-Parser brechen lautlos — eine Kalender-Neugestaltung oder eine API-Änderung ohne Ankündigung. Die Telemetrie meldet eine degradierte Quelle innerhalb eines Aktualisierungszyklus. Die Kalenderansicht des Traders degradiert sanft; sie wird nicht dunkel.
Die Frontend-Codebasis erreichte bis Ende 2024 325 Commits. Das Backend überschritt 541. Die Gamma-Engine, die sich am wenigsten verändert hat, steht bei 59. Das Verhältnis ist eine faire Karte davon, wo der Aufwand tatsächlich lag: nicht in der Quant-Mathematik — die setzte sich früh — sondern in der kontinuierlichen Wartung der Datenschicht darunter.
Wir haben innerhalb einer Woche nach dem Livegang aufgehört, dafür eine separate Tabelle zu pflegen. Es macht den Abgleich, den wir von Hand machten, und es weiß, wie der Markt aussieht, während es das tut.