Warum Event Sourcing Polymarket-Handelssysteme vor Zustandstrift schützt

Ein hochmodernes Handelssystem für Echtzeitmärkte wie Polymarket zu entwickeln, klingt nach einer technischen Herausforderung. Doch die größte Hürde lag nicht in der Implementierung komplexer Handelsstrategien oder der Ausführung von Orders. Das Problem war subtiler, aber folgenreicher: Zustandstrift – ein schleichender Verlust der Synchronisation zwischen dem internen Systemzustand und der tatsächlichen Marktlage.

Die unsichtbare Gefahr: Was Zustandstrift bedeutet

Zustandstrift entsteht, wenn ein System über längere Zeit hinweg nicht mehr mit der Realität übereinstimmt, ohne dass es zu einem offensichtlichen Fehler kommt. Im Fall eines Handelsbots bei Polymarket äußerte sich dies auf folgende Weise:

• Falsche Positionsberechnungen: Der Bot ging von nicht existierenden Handelspositionen aus.
• Mehrfache Risikoexposition: Dasselbe Asset wurde mehrfach als offen geführt, obwohl es nur einmal gehandelt wurde.
• Abweichungen zwischen Bot-Logik und Markt: Der interne Zustand des Bots stimmte nicht mit den tatsächlichen Marktaktivitäten überein.

Das Tückische daran: Es gab keinen Absturz, keine Fehlermeldung – nur eine stille, aber systematische Abweichung von der Realität. Erst nach gründlicher Analyse wurde klar, dass der Bot über Wochen hinweg falsche Entscheidungen traf, ohne dass jemand es bemerkte.

Die Ursachen: Warum Systeme langsam aus der Spur geraten

Mehrere technische Faktoren können Zustandstrift begünstigen, insbesondere in komplexen Echtzeitumgebungen wie Handelsplattformen. Die häufigsten Ursachen waren in diesem Fall:

• Verpasste WebSocket-Updates: Der Bot erhielt nicht alle Marktupdates, weil die Verbindung instabil war oder Nachrichten verloren gingen.
• Verzögerte API-Antworten: Bestellungen oder Marktdaten wurden mit zeitlicher Verzögerung verarbeitet, was zu inkonsistenten Zuständen führte.

• Teilweise Ausführungen: Orders wurden nur teilweise erfüllt, aber das System berücksichtigte dies nicht korrekt.
• Doppelte Ereignisse: Dasselbe Ereignis wurde mehrfach verarbeitet, was zu doppelten Buchungen führte.
• Fehlende Ereignisse: Wichtige Marktaktivitäten wurden nicht erfasst, weil sie beispielsweise aufgrund von Netzwerkproblemen nicht übertragen wurden.
• Annahmen über den In-Memory-Zustand: Das System ging davon aus, dass der aktuelle Zustand im Arbeitsspeicher immer korrekt sei – eine gefährliche Annahme in verteilten Umgebungen.

Der Kern des Problems lag in einer falschen Grundannahme: Das System vertraute seinem eigenen Speicherzustand mehr als der tatsächlichen Marktlage. Doch Arbeitsspeicher ist flüchtig, und selbst bei sorgfältiger Programmierung können Ereignisse verloren gehen oder falsch interpretiert werden.

Event Sourcing: Die Lösung gegen stille Inkonistenz

Um Zustandstrift zu vermeiden, setzt das Team auf Event Sourcing – ein Architekturprinzip, bei dem nicht der aktuelle Zustand, sondern die Ereignisse gespeichert werden, die zu diesem Zustand führen. Statt also Positionen oder Kontostände direkt zu speichern, werden alle relevanten Marktaktivitäten als unveränderliche Ereignisse erfasst:

• Handelsereignisse: Jeder Kauf oder Verkauf wird als separates Ereignis protokolliert.
• Order-Ereignisse: Alle erteilten Orders werden mit Zeitstempeln und Status dokumentiert.
• Ausführungsereignisse: Jede Teilausführung einer Order wird als eigenes Ereignis gespeichert.

Der aktuelle Zustand wird nicht gespeichert, sondern aus der Historie aller Ereignisse rekonstruiert. Das hat mehrere Vorteile:

• Deterministische Berechnung: Der Zustand ist immer reproduzierbar, solange die Ereignishistorie vollständig ist.
• Replay-Fähigkeit: Bei Fehlern oder Systemausfällen kann der Zustand zu jedem Zeitpunkt neu aufgebaut werden.
• Transparenz: Jede Änderung lässt sich lückenlos nachvollziehen.

Architektur: Wie Event Sourcing umgesetzt wird

Die Implementierung folgt einem klaren Schema:

1. Ereignisprotokoll: Alle relevanten Marktaktivitäten werden in einem unveränderlichen Log gespeichert.
2. Zustandsneuberechnung: Der aktuelle Zustand wird bei Bedarf aus den Ereignissen abgeleitet.
3. Aktueller Zustand: Für schnelle Abfragen wird der Zustand im Speicher vorgehalten, aber er kann jederzeit neu berechnet werden.

Zusätzlich wurde eine Reconciliation-Schicht eingeführt, die regelmäßig prüft:

• Werden die tatsächlichen Positionen auf der Handelsplattform mit den intern berechneten Positionen abgeglichen?
• Gibt es Abweichungen, werden diese korrigiert und die Ereignishistorie angepasst.

Die Ergebnisse: Zuverlässigkeit durch rekonstruierbare Zustände

Nach der Umstellung auf Event Sourcing zeigte sich schnell, dass die zuvor beobachteten Probleme der Vergangenheit angehörten:

• Keine stillen Inkonistenzen mehr: Der Systemzustand entsprach immer der Realität.
• Einfacheres Debugging: Fehler lassen sich durch Analyse der Ereignishistorie schneller finden und beheben.
• Wiederherstellbarkeit: Selbst nach einem Systemausfall oder Datenverlust kann der Zustand aus den Ereignissen neu aufgebaut werden.
• Zuverlässige Zustandsverfolgung: Jede Änderung ist nachvollziehbar und reproduzierbar.

Die wichtigste Erkenntnis daraus: In Handelssystemen sollte der Zustand nicht gespeichert, sondern rekonstruiert werden. Denn nur so lässt sich sicherstellen, dass er immer mit der tatsächlichen Marktlage übereinstimmt.

Fazit: Event Sourcing als Standard für Handelsarchitekturen

Die Erfahrung bei Polymarket zeigt, dass Zustandstrift kein seltenes Problem ist – es ist eine natürliche Konsequenz komplexer Echtzeitsysteme. Event Sourcing bietet eine elegante Lösung, indem es die Abhängigkeit von flüchtigen Speicherzuständen eliminiert und stattdessen auf eine verlässliche, nachvollziehbare Ereignishistorie setzt. Für Entwickler von Handelsplattformen, Börsenanwendungen oder anderen finanztechnischen Systemen könnte diese Methode zum neuen Standard werden.

Die nächste Generation von Handelsplattformen wird nicht nur schneller, sondern vor allem zuverlässiger sein – und Event Sourcing ist ein zentraler Baustein dafür.