Technik & Architektur
Die Domäne ist von Auditierbarkeit, Konsistenz und Echtzeit getrieben. Das rückt OMS und FIX, Streaming-Plattformen, Event Sourcing, ein verlässliches Ledger mit Reconciliation und idempotente Order-Verarbeitung ins Zentrum — Regulatorik wird hier zu nicht-funktionalen Anforderungen.
Die Systemlandschaft
Im Kern steht ein Order Management System (OMS), das den gesamten Lebenszyklus abdeckt — Capture → Validate → Route → Execute → Post-Trade. Drumherum gruppieren sich Pre-Trade-Risk-Engine, Trading-Gateway, Market-Data-Feeds, Ledger, Steuer-/Reporting-Module, KYC/AML-Services und — bei Vollbanken — ein Core-Banking-System.
Der kritische Pfad (Order → Risk → Ausführung) läuft synchron und idempotent; Marktdaten und Read-Views skalieren separat über das Event-Backbone.
Die Architektur ist meist service- bzw. eventorientiert: Teams besitzen ihre Services und CI/CD, Domain-Driven Design strukturiert die Schnitte. Entscheidend ist die Trennung des kritischen Pfads (Order → Risk → Ausführung) von den skalierbaren Read-Pfaden (Marktdaten, Depotansicht).
Order-Routing & FIX
Zu Börsen und Liquiditätsanbietern ist das FIX-Protokoll (Financial Information eXchange) der De-facto-Standard. Zwei Nachrichtentypen tragen den Kern des Geschäfts:
- 35=D — New Order Single
- Die Order vom Broker an den Handelsplatz: Instrument, Seite, Menge, Typ, Limit.
- 35=8 — Execution Report
- Die Rückmeldung: angenommen, (teil-)ausgeführt, abgelehnt — mit Kurs und Stückzahl.
Zusätzliche Drop-Copy-FIX-Sessions spiegeln Ausführungen an Reporting- und Reconciliation-Systeme. Zum Frontend hin dominieren REST und WebSocket; FIX bleibt der Maschinenraum nach außen. Für einen Retail-Neobroker zählt dabei nicht HFT-Latenz, sondern Zuverlässigkeit, Korrektheit und Auditierbarkeit.
Echtzeit-Kursdaten
Kursupdates werden über persistente WebSocket-Verbindungen an die Clients gepusht (statt Polling) — mit Heartbeats, Auto-Reconnect und Kompression. Serverseitig verteilen Redis Pub/Sub oder Kafka-Topics die Updates an die richtigen WebSocket-Server, mit Subscription-Management pro Symbol.
- Conflation / Throttling — hochfrequente Updates (100+/s) werden auf für mobile Clients sinnvolle Raten verdichtet (z. B. alle 100–500 ms).
- Binärformate — Protobuf oder MessagePack sparen Bandbreite auf zellularen Verbindungen.
- Entitlement-Management — stellt sicher, dass Nutzer nur lizenzierte Daten erhalten (Echtzeit vs. verzögert).
Event-Driven Architecture & Event Sourcing
Event Sourcing speichert nicht den aktuellen Zustand, sondern jede Zustandsänderung als unveränderliches Event in einem Append-only-Log. Der aktuelle Zustand entsteht durch Replay. Im Finanzkontext ist das attraktiv, weil es genau die regulatorischen Anforderungen bedient:
Der Zustand wird nie überschrieben, sondern durch Replay aller Events rekonstruiert. Das liefert den von der Regulatorik geforderten lückenlosen Audit-Trail — und Debugging per Replay. Preis: Eventual Consistency und Schema-Evolution.
- Lückenloser Audit-Trail — „der Kunde hatte vor zwei Monaten um 13:30 Uhr exakt 901 €“ lässt sich exakt rekonstruieren.
- Rückwirkende Regeln — Geschäftsregeln können auf historische Events neu angewandt werden.
- Debugging per Replay — Root-Cause-Analyse durch erneutes Abspielen.
Oft kombiniert mit CQRS (getrennte Schreib-/Lesemodelle), weil Read- und Write-Last stark divergieren und unabhängig skaliert werden müssen. Der Preis: Eventual Consistency, Schema-Evolution der Events und höhere Komplexität — weshalb erfahrene Architekten das Muster nur dort einsetzen, wo der Nutzen die Komplexität rechtfertigt.
Event Sourcing und ein Double-Entry-Ledger sind begründete Branchenmuster — aber für Trade Republic oder Scalable nicht explizit öffentlich als exakte Implementierung belegt. Beim konkreten Anbieter muss die reale Architektur erfragt werden (siehe Vorbehalte).
Ledger, Reconciliation, Idempotenz
Das Buchhaltungssystem muss jederzeit Bestand und Cash-Saldo korrekt kennen und gegen die Bestände bei CSD/Depotbank sowie gegen Handelsplatz-Bestätigungen abgleichen — Reconciliation. Branchenüblich (und regulatorisch motiviert) ist eine unveränderliche, ereignisbasierte Buchung.
- Konsistenz vor Verfügbarkeit (für Geld)
- Im CAP-Trade-off priorisieren Geld- und Positionsbuchungen Konsistenz. Für Marktdaten und Read-Views ist Availability mit Eventual Consistency akzeptabel.
- Idempotenz von Orders
- Bei Retries oder Netzwerkfehlern darf eine Order nicht doppelt ausgeführt werden. Idempotency-Keys und Deduplizierung sind kritisch auf dem Order-Pfad.
Verfügbarkeit & Failure Modes
Verfügbarkeit ist geschäftskritisch — und der Referenz-Failure-Mode ist bekannt: Bei extremer Volatilität (GameStop, Januar 2021; erneut April 2025) hatten Plattformen Probleme und schränkten Käufe ein. 2021 gingen über 4.000 BaFin-Beschwerden gegen Trade Republic ein.
Volatilitätsspitzen sind kein Ausnahmefall, sondern ein Designkriterium: Lasttests für genau diese Szenarien, Pre-Trade-Risk im Sub-Sekunden-Bereich auf dem kritischen Pfad und Kill-Switch-Mechanismen bei Limitverletzungen gehören zur Pflicht — ebenso Reconciliation-, Idempotenz- und (bei Event Sourcing) Replay-Tests.
Konkrete Stacks
Aus Engineering-Blogs und Stellenanzeigen lässt sich rekonstruieren, was eingesetzt wird (kein vollständiges Architekturbild):
| Bereich | Trade Republic | Scalable Capital |
|---|---|---|
| Backbone | Kafka als „central nervous system“ (self-hosted, multi-cluster) | event-driven / Microservices (Kafka nicht explizit belegt) |
| Backend | JVM: Kotlin, Spring, Vert.x, Hibernate/jOOQ, Flyway; einzelne Services in Haskell; Go für Infra | Kotlin/Java mit Spring Boot, GraphQL |
| Cloud / Betrieb | AWS mit Kubernetes; GitHub Actions/Buildkite; Backstage, Temporal | AWS (ECS, Fargate, Lambda), Multi-Account, Terraform |
| Frontend | Android in Kotlin (Coroutines/Flow, Retrofit, REST) | „Service in a day“-Templates; DevOps-Kultur |
Beide Bilder zeigen denselben roten Faden der Domäne: JVM-zentriert, eventgetrieben, cloud-nativ — mit Streaming als Rückgrat dort, wo Entkopplung und Auditierbarkeit zusammenkommen.