Wie man Fail-Safe-Verarbeitung von Millionen von Transaktionen pro Tag aufbaut

Vollständiger Artikel

💡 Technisches Material für Produkt- und Plattformteams der Fintech-/Glücksspiel- und verwandten Branchen. Kein Aufruf zum Spiel. Unter „Transaktionen“ verstehen wir Geld-/Kontotransaktionen (Abbuchung, Gutschrift, Überweisung, Settlement, Rückgabe).

1) Was fail-safe für Transaktionen bedeutet

Fail-Safe ist, wenn jede fehlgeschlagene Situation entweder zu einem sicheren Stopp oder zu einem kompensierbaren Zustand führt, ohne Geld und Daten zu verlieren. Die Ziele sind:

„Doppelte Belastungen/Gutschriften“ = 0.
Verlorene Transaktionen/Ereignisse = 0.
Vorhersagbare SLOs durch Latenz/Lieferung, klare Degradationsmodi und DRs.

Grundlage sind monetäre Invarianten (die Wahrheit des Gleichgewichts an einem Ort), Idempotenz, die vereinbarte Lieferung von Ereignissen.

2) Architekturprinzipien (kurz)

1. Single source of truth: Bilanz und Buchhaltung - bei Ledger/Wallet. Die Dienste um halten die Zustände der Prozesse, nicht das Geld.

2. „Idempotency everywhere“: Alle „record“ -Operationen akzeptieren den „Idempotency-Key“; Wiederholung gibt das gleiche Ergebnis zurück.

3. Event mit Liefergarantie: Outbox/CDC, Warteschlangen, DLQ, Dedup.

4. Sagas und Kompensationen, keine „manuellen Bearbeitungen“.

5. Rückdruck und Prioritäten: Das System verlangsamt sich, bricht aber nicht zusammen.

6. Standardbeobachtbarkeit: strukturierte Protokolle, Tracing, Metriken.

7. Multi-Region und DR: Asset-Asset/Asset-Passiv, regelmäßige Übungen.

3) Referenztopologie


Edge/API GW ──Command API ──App Service (Sagas)
│           │
│         (Outbox TX)

RateLimit     Outbox Table ──Publisher ──Kafka/Pulsar ──Consumers
│                      │
WAF                     └─DLQ/Replay
│
└─Ledger/Wallet (ACID, idempotent debit/credit)
│
└─CDC/Changefeed ──DWH/BI/Recon

Schlüsselorte: Outbox (atomare Aufzeichnung des Befehls und „Entwurf“ des Ereignisses), Publisher (genau eine Lieferung), Verbraucher (idempotent, mit Dedup-Schlüssel), DLQ/Replay (kontrollierte Wiederholungen).

4) Monetäre Invarianten und Konsistenz

True by Balance - Ledger (ACID, serialisierbare Transaktionen oder strikte Reihenfolge nach Konto).

Die Geldkommandos: 'debit', 'credit', 'hold', 'commit', 'rollback' sind idempotent.

Die kombinierten Prozesse sind wie Sagas aufgebaut:

„authorize → settle → credit“ (Einzahlung/Settlement), „request → submit → settled/failed“ (Zahlung/Auszahlung), „refund/void“ (Entschädigung).
Keine direkten Änderungen der Bilanzen unter Umgehung von Ledger.

5) Idempotenz: Schlüsselentwurf

Der Schlüssel muss den Geschäftsvorgang eindeutig identifizieren:

`bet_id+amount+currency`, `payment_intent+capture_id`, `payout_id`, `chain_txid`.
Speichern Sie das Ergebnis nach Schlüssel (response cache). Die Wiederholung mit dem gleichen Schlüssel → den gleichen body/status.
Kontrollieren Sie die Nichtübereinstimmung: der gleiche Schlüssel mit einer anderen Summe → 'IDEMPOTENCY _ MISMATCH'.

6) Warteschlangen, Ordnung und Dedup

Exactly-once-Effekte werden nicht durch Transport erreicht, sondern durch idempotente Consumer + Dedup-Storage (LRU/Redis/DB c TTL).

Halten Sie die Reihenfolge nach Schlüssel (partition key = 'account _ id/round _ id/player _ id').

Für „heterogene“ Schlüssel - Statusversionierung und Switches (State Machine per Entity).

DLQ ist Pflicht: nach N Versuchen - zu einem isolierten Thema mit menschlich lesbarer Ursache.

7) Outbox/CDC: Warum Ereignisse „nicht verloren“ gehen

Im Rahmen einer Transaktion erfassen wir in der Service-DB sowohl die Geschäftsänderung als auch den Eintrag in die Outbox.

Ein separater Publisher liest die Outbox und veröffentlicht sie mit der Bestätigung im Bus.

Alternativ - CDC (Change Data Capture) auf DB-Ebene (Debezium/Replikationsprotokoll).

Keine „Ereignisprotokolle“ an der Transaktion vorbei sind eine Verlustquelle.

8) Rückdruck und Prioritäten

Token-Baquets und Eintrittsquoten (per tenant/brand/region).

Warteschlangen mit Priorität: Geldwege über Promo/Telemetrie.

Bei Überlast: Modi 'keine neuen Sessions/Requests', Einfrieren von Sekundär-Fich, Kernel-Erhaltung.

Auto-Degradation: Reduzieren Sie die Häufigkeit von Hintergrundaufgaben, erweitern Sie kritische Worker dynamisch.

9) Multiregionale Nachhaltigkeit

Asset-Asset für APIs und Warteschlangen, lokaler Ledger (oder global mit Sharding nach Region/Währung).

Datenresidenz: Geld/PII/Zeitschriften werden nicht ohne explizite Regeln gekreuzt.

Die Replikation von Ereignissen ist interregional - asynchron, mit der Bezeichnung 'region'.

RPO/RTO: Ziel RPO ≤ 5 Minuten, RTO ≤ 30 Minuten; regelmäßig überprüfen.

10) SLO/SLI und Dashboards

Richtlinien (Beispiel):

p95 'authorize/debit/credit' <150-300 ms (interner Pfad).
p95 Ende-zu-Ende „komanda→sobytiye im Bus“ <1-2 s.
Lieferung von Webhooks/externen Ereignissen p99 <5 min.
„Verlorene/doppelte Transaktionen“ = 0 (Vertragsprüfung).

Metriken: latency p50/p95/p99, error-rate (4xx/5xx/business), consumer/queue lag, retry storms, settle lag, webhook lag, DLQ size, frequency 'IDEMPOTENCY _ MISMATCH'.

11) Beobachtbarkeit und Auditierung

Strukturierte JSON-Protokolle mit 'trace _ id', 'idempotency _ key', Business-ID, Fehlercodes.

OpenTelemetry: HTTP/gRPC/DB/Bus-Tracing, Span-Sags.

WORM-Audit: unveränderliche Protokolle kritischer Änderungen (Limits, Keys, Configs Promo/Jackpots).

PII/Secret Masking, Regional Bakets, RBAC/ABAC für Log-Zugriff.

12) Zuverlässigkeitsprüfung

Vertragstests: Wiederholung/Duplikate, Out-of-Order, Idempotenz, Dedup.

Last: Spitzenprofil (x10), Stabilität von Warteschlangen und DB.

Chaos-Fälle: Ledger/Wallet Drop, Warteschlange/Region Dump, CDC Verzögerungen, „Sturm“ Retraits.

Game Days: regelmäßige Übungen von DR und Zwischenfällen, mit MTTR-Messung.

13) Speicher und Daten

OLTP für Geld: Transaktions-DB (RPO≈0), strenge Indizes, serialisierbare Ebenen für kritische Entitäten.

Cache (Redis) - nur für die Beschleunigung, nicht für die „Wahrheit“. TTL + jitter, Schutz vor Cache Stampede.

OLAP/DWH - für Berichte/Analysen. Ströme von CDC/Bus, keine OLTP-Belastung.

Die Datenschemata werden versioniert; Migrationen ohne Downtime (expand/contract).

14) Orchestrierung von Retrays

Exponentieller Backoff + Jitter, Deadlines/Timeout auf RPC.

Idempotente Wiederholung auf jeder Schicht (Kunde → Service → Verbraucher).

Rückzugsquoten, um sich vor „Stürmen“ zu schützen (Circuit Breaker, Hedged Requests, wo angemessen).

Replay von DLQ nur in „sichere“ Fenster, mit Geschwindigkeitsbegrenzung.

15) Transportsicherheit

mTLS ist überall S2S, kurzlebige Token (OAuth2 CC), Signaturen von Körpern (HMAC/EdDSA) für Webhooks.

Geheimnisse in Vault/HSM, Rotation, Schlüssel pro Marke/Region.

Politik least privilege, „vier Augen“ auf manuelle Operationen.

16) Beispielverträge (Fragmente)

Idempotent Debit Team


POST /v1/wallet/debit
Headers: X-Idempotency-Key: debit_pi_001, X-Trace-Id: tr_a1b2
{
"account_id":"acc_42",  "amount":{"minor_units":5000,"currency":"EUR"},  "reason":"payout",  "reference_id":"po_001"
}
→ 200 { "status":"committed", "entry_id":"e_77" }
(Wiederholung → gleiche Antwort)

Event aus der Outbox

json
{
"event_id":"uuid",  "event_type":"wallet. debit. committed",  "occurred_at":"2025-10-23T16:21:05Z",  "account_id":"acc_42",  "amount_minor":5000,  "currency":"EUR",  "reference_id":"po_001",  "idempotency_key":"debit_pi_001",  "schema_version":"1. 3. 0"
}

17) Checklisten

Plattform/Betreiber

Die Wahrheit in der Balance ist ein Ledger; Es gibt keine Umwege.
Alle Schreibvorgänge mit 'Idempotency-Key'; Die Antwort auf den Schlüssel wird gespeichert.
Outbox/CDC für alle Domäneneinträge, DLQ und Managed Replay.
Warteschlangen mit Prioritäten, Rückdruck, Degradationsmodi.
Partition-keys werden nach Geschäftsschlüsseln ausgewählt; Verbraucher sind idempotent.
SLO-Dashboards, OpenTelemetry, WORM-Audit.
Regelmäßige DR/xaoc-Übungen, Kontrakt-/Belastungstests.
Datenresidenz, Verschlüsselung, Vault/HSM, Schlüsselrotation.

Anbieter/Integrationen

Send 'Trace-Id '/' Idempotency-Key', bereit für die erneute Lieferung.
Webhooks werden signiert und dedupliziert.
Die Versionen der Schemata/Verträge werden eingehalten (semver, deprecation).

18) Rote Fahnen (Anti-Muster)

Die Bilanz ändert sich per Webhook ohne Team bei Ledger.

Keine Idempotenz → doppelte Abschreibungen/Kredite.

Publizieren von Ereignissen unter Umgehung von Outbox/CDC.

Ein Monolith ohne Hinterdruck: Der Verkehrsspitze fällt alles runter.

Mischung aus OLTP und Berichten: BI trifft die Kampfdatenbank.

Kein DLQ/Replay; „stilles“ Verschlucken von Fehlern.

Keine regionale Isolierung von PII/Geld; gemeinsame Schlüssel für mehrere Marken.

Manuelle Korrekturen von Waagen/Status in der DB.

19) Das Ergebnis

Bei der fail-safe-Verarbeitung von Millionen von Transaktionen pro Tag geht es um Invarianten und Disziplin: eine einzige Quelle der Wahrheit, idempotente Teams, Sagas und Outbox/CDC, Ordnung und Dedup in Warteschlangen, Beobachtbarkeit und kontrollierte Degradation. Fügen Sie Zugriffsmandate, DR-Praktiken und regelmäßige Übungen hinzu - und erhalten Sie ein System, in dem sich das Geld schnell und nur einmal bewegt, Ereignisse nicht verloren gehen und das Verkehrswachstum und die Störungen eher zu überschaubaren Risiken als zu Überraschungen werden.