Jak zbudować bezpieczne przetwarzanie milionów transakcji dziennie

Pełny artykuł

💡 Materiał techniczny dla zespołów produktów i platform z fintech/gier i związanych z nimi branż. Ani telefonu do zabawy. Przez „transakcje” rozumiemy transakcje pieniężne/księgowe (debetowanie, kredytowanie, przelew, rozrachunek, zwrot).

1) Co oznacza bezpieczne dla transakcji

Zabezpieczenie awarii jest wtedy, gdy każda nieudana sytuacja prowadzi do bezpiecznego zatrzymania lub skompensowanego stanu bez utraty pieniędzy i danych. Cele:

„Podwójne obciążenia/kredyty” = 0.
Utracone transakcje/zdarzenia = 0.
Przewidywalne SLO przez opóźnienie/dostawę, przezroczyste tryby degradacji i DR.

Podstawa - niezmienne walutowe (prawdziwe saldo w jednym miejscu), idempotencja, uzgodnione dostarczenie wydarzeń.

2) Zasady architektoniczne (krótkie)

1. Pojedyncze źródło prawdy: bilans i księgowość - w Ledger/Wallet. Usługi wokół utrzymują stan procesów, a nie pieniędzy.

2. Idempotencja wszędzie: wszystkie operacje „napisz” biorą 'Idempotence-Key'; powtórzenie zwraca ten sam wynik.

3. Wydarzenie z gwarancją dostawy: outbox/CDC, kolejki, DLQ, deadup.

4. Sagi i odszkodowania, a nie „ręczne edycje”.

5. Ciśnienie wsteczne i priorytety: system spowalnia, ale nie upada.

6. Domyślna obserwowalność: ustrukturyzowane dzienniki, śledzenie, mierniki.

7. Multi-region i DR: aktywa-aktywa/aktywa-zobowiązania, regularne ćwiczenia.

3) Topologia odniesienia


Krawędź/API GW
│           │
(Outbox TX)

 Limit Stolik OutboxEplaymarKafka/Pulsar
│                      │
└─DLQ/Replay WAF
│
└─Ledger/Wallet (ACID, idempotent debet/kredyt)
│
└─CDC/Changefeed „DWH/BI/Recon”

Kluczowe miejsca: Outbox (rekord atomowy zespołu i „projekt” wydarzenia), Wydawca (dokładnie jedna dostawa), Konsumenci (idempotent, z kluczem dedup), DLQ/Replay (kontrolowane powtórzenia).

4) Niezmienne środki pieniężne i ich spójność

True by balance - Ledger (ACID, transakcje serializowane lub ścisłe zamawianie według konta).

Polecenia pieniężne: 'debet', 'credit', 'hold', 'commit', 'rollback' są idempotentne.

Połączone procesy są budowane jak sagi:

„authorize → settle → credit”, „request → submit → settled/failed”, „refund/void”.
Brak bezpośrednich edycji bilansu omijających Ledger.

5) Idempotencja: kluczowy projekt

Klucz musi jednoznacznie zidentyfikować transakcję biznesową:

'bet _ id + kwota + waluta', 'payment _ intent + capture _ id',' payout _ id', 'chain _ txid'.
Wynik należy przechowywać za pomocą klucza (pamięć podręczna odpowiedzi). Powtórz z tym samym kluczem → ten sam organ/status.
Niedopasowanie monitoringu - ten sam klucz z różną kwotą → „IDEMPOTENCY _ MISMATCH”.

6) Kolejki, porządek i deadup

Dokładnie raz efekty są osiągane nie przez transport, ale przez konsumentów idempotent + dedup storage (LRU/Redis/DB c TTL).

Zachowaj kolejność kluczy (klucz partycji = 'account _ id/round _ id/player _ id').

Dla „niejednorodnych” kluczy - maszyna stanu na jednostkę.

DLQ jest obowiązkowe: po próbach N - w odosobniony temat z ludzką przyczyną.

7) Outbox/CDC: Dlaczego wydarzenia „nie zgubić”

W ramach jednej transakcji rejestrujemy zarówno zmianę firmy, jak i wpis do bazy danych serwisu.

Osobny wydawca czyta skrzynkę i publikuje ją do autobusu potwierdzającego.

Alternatywnie, CDC (Change Data Capture) na poziomie bazy danych (Debezium/replikacja log).

Żadne „dzienniki zdarzeń” poza transakcją nie są źródłem strat.

8) Ciśnienie wsteczne i priorytety

Wiadra tokenowe i kwoty wejściowe (na najemcę/markę/region).

Kolejki priorytetowe: ścieżki pieniężne powyżej promo/telemetrii.

Po przeciążeniu: tryby 'bez nowych sesji/żądań', zamrażanie funkcji wtórnych, zapisywanie jądra.

Auto-degradacja: zmniejszyć częstotliwość zadań tła, dynamicznie rozszerzyć pracowników krytycznych.

9) Zrównoważony rozwój wielregionalny

Aktywa dla API i kolejek, lokalne Ledger (lub globalne z shading region/waluta).

Pobyt danych: Pieniądze/PII/dzienniki nie są przekraczane bez wyraźnych zasad.

Replikacja zdarzeń jest międzyregionalna - asynchroniczna, oznaczona jako „region”.

RPO/RTO: cel RPO ≤ 5 minut, RTO ≤ 30 minut; regularnie sprawdzać.

10) SLO/SLI i deski rozdzielcze

Punkty orientacyjne (przykład):

p95ng authorize/debit/credit '<150-300 ms (ścieżka wewnętrzna).
p95 end-to-end „bus komanda → sobytiye” <1-2 s.
Dostawa haków/zdarzeń zewnętrznych p99 <5 min.
Transakcje utracone/duplikowane = 0 (kontrole umów).

Metryki: opóźnienie p50/p95/p99, szybkość błędów (4xx/5xx/business), opóźnienie konsumenckie/kolejkowe, burze wsteczne, opóźnienie rozliczenia, opóźnienie haka internetowego, rozmiar DLQ, częstotliwość „IDEMPOTENCY _ MISMATCH”.

11) Obserwowalność i audyt

Ustrukturyzowane dzienniki JSON z 'trace _ id',' idempotence _ key ', business ID, kody błędów.

OpenTelemetry: HTTP/gRPC/DB/bus odwzorowanie, przęsła sagi.

Audyt WORM: niezmienne rejestry zmian krytycznych (limity, klawisze, konfiguracje promo/jackpot).

PII/tajne maskowanie, regionalne wiadra, RBAC/ABAC dla dostępu do dziennika.

12) Badanie niezawodności

Testy kontraktowe: powtarzanie/duplikaty, nieporządek, iempotencja, dedup.

Obciążenie: profil szczytowy (x10), stabilność kolejek i DB.

Przypadki chaosu: Ledger/kropla portfela, kolejka/porzucenie regionów, opóźnienia CDC, retray „burza”

Dni gry: regularne wiertła DR i incydenty, z mierzonym MTTR.

13) Przechowywanie i dane

OLTP dla pieniędzy: transakcyjna baza danych (RPO ≤ 0), ścisłe indeksy, możliwy do serializacji poziom dla podmiotów krytycznych.

Cache (Redis) - tylko dla przyspieszenia, a nie dla "prawdy. "TTL + jitter, zabezpieczenie pamięci podręcznej.

OLAP/DWH - dla raportów/analiz. Przepływa z CDC/autobus, bez obciążenia OLTP.

Schematy danych są zmieniane; migracja bez przestoju (rozszerzenie/umowa).

14) Orkiestra Retras

Wykładnicze backoff + jitter, terminy/czas na RPC.

Idempotent powtarzać na każdej warstwie (klient → usługa → konsument).

Kwoty Retrai, ochrona przed „burzami” (wyłącznik, bezpieczne wnioski, w stosownych przypadkach).

Powtórz z DLQ tylko do „bezpiecznych” okien, z ograniczeniem prędkości.

15) Bezpieczeństwo transportu

mTLS wszędzie S2S, krótkotrwałe żetony (OAuth2 CC), podpisy nadwozia (HMAC/EdDSA) dla haków internetowych.

Sekrety w skarbcu/HSM, obrót, klawisze na markę/region.

Politycy najmniej przywilej, „cztery oczy” na operacje ręczne.

16) Zamówienia próbne (fragmenty)

Polecenie Idempotent Debit


POST/v1/portfel/debet
Nagłówki: X-Idempotency-Key: debit_pi_001, X-Trace-Id: tr_a1b2
{
„account_id":"acc_42,” „kwota „: {„minor _ units „: 5000,” currency”:” EUR”}, „reason „:” payout”, „reference_id":"po_001”
}
→ 200 {„status „: „zaangażowany”, „entry_id":"e_77”}
(powtórz → ta sama odpowiedź)

Zdarzenie ze skrzynki zewnętrznej

json
{
"event_id":"uuid," "event_type":"wallet. debet. zaangażowane „,” occurred_at":"2025-10-23T16:21:05Z, „” account_id":"acc_42, „” amount_minor":5000 „,” waluta „:” EUR „,” reference_id":"po_001, „idempotency_key":"debit_pi_001,” schema_version":"1. 3. 0"
}

17) Listy kontrolne

Platforma/Operator

True on balance - one Ledger; Nie ma żadnych prac.
Wszystkie operacje pisania „Idempotency-Key”; odpowiedź klucza jest przechowywana.
Outbox/CDC do wszystkich rekordów domeny, DLQ i zarządzanych powtórzeń.
Kolejki priorytetowe, ciśnienie wsteczne, tryby degradacji.
Klucze partycji są wybierane przez klucze biznesowe; konsumenci są idempotentni.
Deski rozdzielcze SLO, OpenTelemetry, audyt WORM.
Regularne ćwiczenia DR/xaoc, testy kontraktowe/obciążeniowe.
Rezydencja danych, szyfrowanie, skarbiec/HSM, rotacja klucza.

Dostawcy/Integracje

Wysyłanie Trace-Id/Idempotency-Key, gotowy do redelivery.
Haki internetowe są podpisywane i zdublowane.
Obserwowane są wersje programów/umów (semver, deprecation).

18) Czerwone flagi (anty-wzory)

Saldo zmienia się przez webhook bez polecenia w Ledger.

Brak idempotencji → podwójne odpisy/kredyty.

Publikacja wydarzeń omijających skrzynkę kontaktową/CDC.

Monolith bez ciśnienia wstecznego: szczyt ruchu sprowadza wszystko w dół.

Mieszanie OLTP i raportów: BI uderza w bazę danych walki.

Brak DLQ/replay; „ciche” spożycie błędów.

brak regionalnego odizolowania PII/pieniędzy; współdzielone klucze przez wiele marek.

Ręczne edycje sald/statusów w bazie danych.

19) Najważniejsze

Bezpieczne przetwarzanie milionów transakcji dziennie jest o niezmiennych i dyscypliny: jedno źródło prawdy, idempotentne polecenia, sagi i outbox/CDC, porządek i deadup w kolejkach, obserwowalność i zarządzana degradacja. Dodaj mandaty dostępu, praktyki DR i regularne ćwiczenia - i uzyskać system, w którym pieniądze poruszają się szybko i tylko raz, wydarzenia nie są tracone, a wzrost ruchu i zakłócenia stają się ryzykiem do zarządzania, a nie niespodziankami.