Cum se construiește procesarea în condiții de siguranță a milioane de tranzacții pe zi

Articol complet

💡 Material tehnic pentru echipe de produse și platforme de fintech/gaming și industrii conexe. Nu este un apel pentru a juca. Prin „tranzacții” înțelegem tranzacții monetare/contabile (debitare, creditare, transfer, decontare, retur).

1) Ce înseamnă fail-safe pentru tranzacții

Fail-safe este atunci când orice situație eșuată duce fie la o oprire sigură, fie la o stare compensată fără a pierde bani și date. Obiective:

„Debite/credite duble” = 0.
Tranzacții/evenimente pierdute = 0.
SLO previzibil prin latență/livrare, moduri clare de degradare și DR.

Bază - invarianți monetari (echilibru adevărat într-un singur loc), idempotență, livrarea convenită a evenimentelor.

2) Principii arhitecturale (scurt)

1. Sursa unică de adevăr: bilanț și contabilitate - în registru/portofel. Serviciile din jur dețin starea proceselor, nu banii.

2. Idempotența peste tot: toate operațiunile „scrie” iau „Idempotency-Key”; repetați întoarce același rezultat.

3. Eveniment cu garanție de livrare: outbox/CDC, cozi, DLQ, deadup.

4. Sagas și compensații, nu „editări manuale”.

5. Presiunea și prioritățile: sistemul încetinește, dar nu se prăbușește.

6. Observabilitate implicită: jurnale structurate, urmărire, valori.

7. Multi-regiune și DR: activ-activ/activ-pasiv, exercitarea regulată.

3) Topologie de referință


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

RateLimit Outbox Tabel ──Publisher ──Kafka/Pulsar ──Consumers
│                      │
└─DLQ/Replay WAF
│
└─Ledger/Wallet (ACID, debit/credit idempotent)
│

Locuri cheie: Outbox (înregistrarea atomică a unei echipe și a unui „proiect” al unui eveniment), Publisher (exact o livrare), Consumatori (idempotent, cu o cheie dedup), DLQ/Replay (repetări controlate).

4) Invarianți monetari și consecvență

True by balance - Ledger (ACID, tranzacții serializabile sau comandă strictă prin cont).

Comenzile de bani: 'debit', 'credit', 'hold',' comite ',' rollback 'sunt idempotente.

Procesele combinate sunt construite ca sagas:

„autorizaţi → soluţionaţi → credit”, „cerere → prezentare → decontare/eşec”, „rambursare/anulare”.
Niciun bilanţ direct nu ocoleşte Ledger.

5) Idempotence: design cheie

Cheia trebuie să identifice în mod unic tranzacția de afaceri:

'bet _ id + suma + moneda', 'payment _ intent + capture _ id',' payout _ id', 'chain _ txid'.
Stocați rezultatul după cheie (memoria cache de răspuns). Repetați cu aceeași cheie → același corp/status.
Monitor nepotrivire - aceeași cheie cu o cantitate diferită → „IDEMPOTENCY _ MISMATCH”.

6) Cozi, ordine și deadup

Exact odată ce efectele sunt obținute nu de transport, ci de consumatori idempotenți + stocare dedup (LRU/Redis/DB c TTL).

Păstrați ordinea cheie (cheia de partiție = 'account _ id/round _ id/player _ id').

Pentru cheile „eterogene” - mașină de stat pe entitate.

DLQ este obligatorie: după încercările N - într-un subiect izolat cu o cauză care poate fi citită de om.

7) Outbox/CDC: De ce evenimentele "nu se pierd'

În cadrul unei tranzacții, înregistrăm atât o schimbare de afaceri, cât și o intrare outbox în baza de date de servicii.

Un editor separat citește outbox-ul și îl publică în autobuzul de confirmare.

Alternativ, CDC (Change Data Capture) la nivelul bazei de date (Debezium/replication log).

Niciun „jurnal de evenimente” trecut de tranzacție nu este o sursă de pierdere.

8) Presiunea de spate și prioritățile

Găleți token și cote de intrare (per chiriaș/marcă/regiune).

Cozi prioritare: trasee de bani deasupra promo/telemetrie.

Când este supraîncărcat: modurile „fără sesiuni/cereri noi”, înghețarea caracteristicilor secundare, salvarea nucleului.

Degradarea automată: reduceți frecvența sarcinilor de fundal, extindeți dinamic lucrătorii critici.

9) Sustenabilitate multiregională

Activ pentru API și cozi, local Ledger (sau global cu regiune/monedă sharding).

Rezidența datelor: Banii/PII/jurnalele nu sunt încrucișate fără reguli explicite.

Replicarea evenimentelor este interregională - asincronă, marcată cu „regiune”.

RPO/RTO: scop RPO ≤ 5 minute, RTO ≤ 30 minute; verificați în mod regulat.

10) SLO/SLI și tablouri de bord

Repere (exemplu):

p95 'authorize/debit/credit' <150-300 ms (cale internă).
p95 end-to-end „komanda→sobytiye de autobuz” <1-2 s.
Livrarea de webhooks/evenimente externe p99 <5 min.
Tranzacții pierdute/duplicate = 0 (controale contractuale).

Valori: latență p50/p95/p99, eroare-rate (4xx/5xx/business), consumator/coadă lag, încercați din nou furtuni, decontare lag, webhook lag, dimensiune DLQ, „IDEMPOTENCY _ MISMATCH” frecvență.

11) Observabilitate și audit

Jurnalele JSON structurate cu 'trace _ id',' idempotency _ key ', business ID, coduri de eroare.

OpenTelemetry: HTTP/gRPC/DB/autobuz de urmărire, se întinde de sagas.

Audit WORM: jurnale critice de schimbare neschimbabile (limite, chei, configurații promo/jackpot).

PII/mascare secretă, găleți regionale, RBAC/ABAC pentru acces jurnal.

12) Testarea fiabilității

Teste contract: repetare/duplicate, out-of-order, idempotency, dedup.

Încărcare: profil de vârf (x10), stabilitatea cozilor și DB.

Cazuri de haos: Ledger/picătură portofel, coadă/regiuni dump, întârzieri CDC, retray „furtună”

Zilele jocului: exerciții regulate DR și incidente, cu MTTR măsurate.

13) Stocare și date

OLTP pentru bani: baza de date tranzacțională (RPO≈0), indici stricți, niveluri serializabile pentru entitățile critice.

Cache (Redis) - numai pentru accelerare, nu pentru "adevăr. "TTL + jitter, cache stampede de protecție.

OLAP/DWH - pentru rapoarte/analize. Curge din CDC/autobuz, fără sarcină pe OLTP.

Schemele de date sunt versionate; migrarea fără timpi morți (extindere/contract).

14) Orchestrarea urmelor

Backoff exponențial + jitter, termene limită/timeout pe RPC.

Repetare idempotentă pe fiecare strat (client → service → consumator).

Cote Retrai, protejați împotriva „furtunilor” (întrerupător de circuit, cereri acoperite, dacă este cazul).

Replay de la DLQ numai la ferestre „sigure”, cu limită de viteză.

15) Siguranța transporturilor

mTLS peste tot S2S, jetoane de scurtă durată (OAuth2 CC), semnături corporale (HMAC/EdDSA) pentru webhook-uri.

Secrete în Vault/HSM, rotație, chei pe brand/regiune.

Politicienii cel mai puțin privilegiu, „patru ochi” pe operațiuni manuale.

16) Contracte de probă (fragmente)

Comanda Debit Idempotent


POST/v1/portofel/debit
Anteturi: X-Idempotency-Key: debit_pi_001, X-Trace-Id: tr_a1b2
{
"account_id":"acc_42," "sumă": {"minor _ units': 5000", valută ":" EUR "}," motiv ":" plată "," reference_id":"po_001 "
}
→ 200 {„status „: „committed”, „entry_id":"e_77”}
(repetați → același răspuns)

Eveniment din outbox

json
{
"event_id":"uuid," "event_type":"wallet. debit. angajat „,”  „ ”  „,” monedă „:” EUR „,”  „ ”. 3. 0"
}

17) Liste de verificare

Platformă/Operator

Adevărat pe echilibru - un registru; nu există soluţii.
Toate operațiunile de scriere cu 'Idempotency-Key'; răspunsul cheie este stocat.
Outbox/CDC la toate înregistrările de domeniu, DLQ și reluarea gestionată.
Cozi prioritare, back-pressure, moduri de degradare.
Cheile de partiție sunt selectate prin chei de afaceri; consumatorii sunt idempotenți.
Tablouri de bord SLO, OpenTelemetry, audit WORM.
Exerciții regulate DR/xaoc, teste de contract/sarcină.
Rezidență de date, criptare, Vault/HSM, rotație cheie.

Furnizori/Integrari

Trimiterea Trace-Id/Idempotency-Key, gata pentru redelivery.
Webhooks sunt semnate și deduplicate.

Se observă versiuni de scheme/contracte (semver, depreciere).

18) Steaguri roșii (anti-modele)

Soldul se schimbă prin webhook fără o comandă în Ledger.

Lipsa idempotenței → a dublei reduceri/credite.

Publicarea evenimentelor ocolind outbox/CDC.

Monolit fără back-pressure: traficul de vârf reduce totul.

Amestecarea OLTP și rapoarte: BI lovește baza de date de luptă.

Absența DLQ/reluare; ingerarea „liniștită” a erorilor.

Nu există PII regional/izolarea banilor; chei partajate pe mai multe branduri.

Modificări manuale ale soldurilor/statusurilor în baza de date.

19) Linia de jos

Procesarea în condiții de siguranță a milioane de tranzacții pe zi este despre invarianți și disciplină: o singură sursă de adevăr, comenzi idempotente, saga și outbox/CDC, ordine și deadup în cozi, observabilitate și degradare gestionată. Adăugați mandate de acces, practici DR și exerciții regulate - și obțineți un sistem în care banii se mișcă rapid și o singură dată, evenimentele nu sunt pierdute, iar creșterea traficului și perturbările devin riscuri ușor de gestionat, nu surprize.