Күніне миллиондаған транзакциялардың fail-safe өңдеуін қалай жасау керек

Мақаланың толық мәтіні

💡 Финтех/ойын және аралас салалардағы азық-түлік және платформалық командаларға арналған техникалық материал. Ойынға шақыру емес. «Транзакциялар» деп ақшалай/есеп операцияларын (есептен шығару, есептеу, аудару, сеттлмент, қайтару) түсінеміз.

1) Транзакциялар үшін fail-safe дегеніміз не?

Fail-safe - бұл кез келген ақаулы жағдай не қауіпсіз тоқтауға, не ақша мен деректерді жоғалтпай өтелетін жағдайға әкелетін жағдай. Мақсаттары:

«Қосарланған дебеттер/кредиттер» = 0.
Жоғалған транзакциялар/оқиғалар = 0.
Жасырындылық/жеткізу бойынша болжамды SLO, нақты тозу режимдері және DR.

Негіз - ақшалай инварианттар (баланстың ақиқаты бір жерде), іспеттілік, оқиғалардың келісілген жеткізілімі.

2) Сәулет қағидаттары (қысқаша)

1. Single source of truth: баланс және бухгалтерия - Ledger/Wallet. Сервистер айналасында ақша емес, процестердің жай-күйін ұстап тұрады.

2. Idempotency everywhere: барлық «жазбалар» операцияларын 'Idempotency-Key' қабылдайды; қайталау сол нәтижені қайтарады.

3. Жеткізу кепілдігімен оқиғалар: outbox/CDC, кезек, DLQ, дедуп.

4. Сағалар мен өтемақылар, «қолмен түзету» емес.

5. Back-pressure және басымдықтар: жүйе баяулайды, бірақ құлдырамайды.

6. Әдепкі бақылау: құрылымдалған логтар, трейсинг, метриктер.

7. Мульти-өңір және DR: актив-актив/актив-пассив, тұрақты оқу-жаттығулар.

3) Референс-топология


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

Түйінді орындар: Outbox (команданың атомарлық жазбасы және оқиғаның «жоба жазбасы»), Publisher (тегіс-бір жеткізу), Consumers (іспеттес, дедуп-кілті бар), DLQ/Replay (бақыланатын қайталаулар).

4) Ақша инварианттары және келісімділік

Баланс бойынша ақиқат - Ledger (ACID, сериалданатын транзакциялар немесе есеп бойынша қатаң реттеу).

Ақша командалары: 'debit', 'credit', 'hold', 'commit', 'rollback' - іспеттес.

Аралас процестер сағалар ретінде құрылады:

'authorize → settle → credit' (депозит/сеттлмент), 'request → submit → settled/failed' (төлем/шығыс), 'refund/void' (өтемақы).
Ledger бағдарламасын айналып өту үшін теңгерімдерді түзету мүмкін емес.

5) Үйлесімділік: кілттердің дизайны

Кілт бизнес-операцияны біржақты сәйкестендіруі тиіс:

`bet_id+amount+currency`, `payment_intent+capture_id`, `payout_id`, `chain_txid`.
Нәтижені (response cache) кілтімен сақтау. Сол кілтпен қайталау → сол body/мәртебе.
Сәйкессіздікті бақылаңыз: басқа сомамен бірдей кілт → 'IDEMPOTENCY _ MISMATCH'.

6) Кезектер, тәртіп және дедуп

Exactly-once әсерлеріне көлікпен емес, демпотенттік консультанттармен + дедуп-қоймамен (LRU/Redis/DB c TTL) қол жеткізіледі.

Кілт бойынша ретті сақтаңыз (partition key = 'account _ id/round _ id/player _ id').

«Әр текті» кілттер үшін - күйді нұсқалау және коммутаторлар (state machine per entity).

DLQ міндетті: N әрекеттерден кейін - оқылатын себебі бар оқшауланған тақырыпқа.

7) Outbox/CDC: оқиғалар неге «жоғалмайды»

Бір транзакция аясында сервистің ДБ-да бизнес өзгерістерді де, outbox-та жазбаны да жазамыз.

Жеке publisher outbox бағдарламасын оқиды және растайтын шинаға жариялайды.

Балама - CDC (Change Data Capture) ДБ деңгейінде (Debezium/репликация журналы).

Транзакциядан кейін ешқандай «оқиғалар логы» жоғалту көзі болып табылады.

8) Back-pressure және басымдықтар

Токен-бакеттер және кіреберістегі квоталар (per tenant/brand/region).

Басымдығы бар кезектер: ақшалай жолдар промо/телеметриядан жоғары.

Шамадан тыс жүктеу кезінде: 'no new sessions/requests' режимдері, екінші фазаларды қатыру, ядроны сақтау.

Авто-деградация: фондық міндеттердің жиілігін қысқарту, сындарлы воркерлерді серпінді кеңейту.

9) Көп аймақтық тұрақтылық

API және кезектер үшін актив-актив, жергілікті Ledger (немесе өңір/валюта бойынша шардингі бар жаһандық).

Data residency: ақша/PII/журналдар нақты ережесіз кроссталмайды.

Аймақаралық оқиғаларды репликалау - асинхрондық, 'region' белгісі бар.

RPO/RTO: RPO ≤ 5 минут, RTO ≤ 30 минут; үнемі тексеріп тұрыңыз.

10) SLO/SLI және дашбордтар

Бағдарлар (мысал):

p95 'authorize/debit/credit' <150-300 мс (ішкі жол).
p95 end-to-end «команда → шинадағы оқиға» <1-2 с.
Вебхуктарды/сыртқы оқиғаларды жеткізу p99 <5 мин.
«Жоғалған/қайталанған транзакциялар» = 0 (келісімшарттық тексерулер).

Өлшемдері: latency p50/p95/p99, error-rate (4xx/5xx/business), consumer/queue lag, retry storms, settle lag, webhook lag, DLQ өлшемі, жиілігі 'IDEMPOTENCY _ MISMATCH'.

11) Бақылау және аудит

'trace _ id', 'idempotency _ key', бизнес-id, қате кодтары бар құрылымдалған JSON логтары.

OpenTelemetry: Trace HTTP/gRPC/DB/шиналар, спан саг.

WORM-аудит: күрделі өзгерістердің өзгермейтін журналдары (лимиттер, кілттер, промо/джекпот конфигтері).

PII/құпияларды бүркемелеу, өңірлік бакеттер, RBAC/ABAC логтарға қол жеткізу.

12) Сенімділікті тестілеу

Келісімшарттық тестілер: қайталау/телнұсқалар, out-of-order, теңсіздік, дедуп.

Жүктемелік: шыңдар профилі (x10), кезектердің орнықтылығы және БД.

Хаос-кейстер: Ledger/әмиянның құлауы, кезектің/аймақтардың үйіндісі, CDC кідіруі, ретрайлардың «дауылы».

Game Days: MTTR өлшеуімен DR және оқыс оқиғалардың тұрақты жаттығулары.

13) Қоймалар және деректер

ALTP ақшаға: транзакциялық ДБ (RPO ≈ 0), қатаң индекстер, критикалық мәні бойынша сериалданатын деңгейлер.

Кэш (Redis) - тек жеделдету үшін, «ақиқат» үшін емес. TTL + jitter, cache stampede қорғанысы.

OLAP/DWH - есептер/талдау үшін. CDC/шинадан OLTP жүктемесіз ағындар.

Деректер схемалары нұсқаланады; (expand/contract).

14) Ретрайлерді оркестрлеу

Экспоненциалды backoff + джиттер, RPC-дегі мерзім/уақыт.

Әрбір қабатта идемпотенттік қайталау (клиент → сервис → тұтынушы).

Ретраға арналған квоталар, «дауылдан» қорғалу (circuit breaker, hedged requests орынды жерде).

DLQ бағдарламасынан тек жылдамдығы шектелген «қауіпсіз» терезелерге көшіру.

15) Көлік қауіпсіздігі

mTLS барлық жерде S2S, қысқа өмір сүретін токендер (OAuth2 CC), вебхуктер үшін дене қолтаңбалары (HMAC/EdDSA).

Vault/HSM құпиялары, ротация, per brand/region кілттері.

least privilege саясаты, қол операцияларына «төрт көз».

16) Үлгі келісімшарттар (фрагменттер)

Демпотенттік дебет командасы


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" }
(қайталау → сол жауап)

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) Чек парақтары

Платформа/оператор

Баланс бойынша ақиқат - бір Ledger; айналып өту жолдары жоқ.
Барлық write-операциялары 'Idempotency-Key'; жауап кілт бойынша сақталады.
Outbox/CDC барлық домендік жазбаларға, DLQ және басқарылатын replay.
Артықшылықтары бар кезектер, back-pressure, тозу режимдері.
Partition-keys бизнес кілттері бойынша таңдалған; тұтынушылар икемді.
SLO-дашбордтар, OpenTelemetry, WORM-аудит.
Тұрақты DR/xaoc-жаттығулар, келісімшарттық/жүктеме тестілері.
Data residency, шифрлау, Vault/HSM, кілттерді айналдыру.

Провайдерлер/интеграциялар

Жіберемін 'Trace-Id '/' Idempotency-Key', қайта жеткізуге дайын.
Вебхактар қол қойылып, дедуплицияланады.
Схемалардың/келісімшарттардың нұсқалары сақталады (semver, deprecation).

18) Қызыл жалаулар (қарсы үлгілер)

Баланс Ledger пәрменінсіз вебхок бойынша өзгереді.

Сәйкессіздіктің болмауы → екі есе есептен шығару/кредиттер.

Оқиғаларды outbox/CDC тексеріп шығу арқылы жариялау.

back-pressure жоқ монолит: трафиктің шыңы бәрін құлатады.

OLTP және есептердің араласуы: BI жауынгерлік БД-ға соққы береді.

DLQ/реплеяның болмауы; қателерді «тыныш» жұту.

PII/ақшаны өңірлік оқшаулау жоқ; бірнеше брендке ортақ кілттер.

ДБ-дағы баланстарды/мәртебелерді қолмен түзету.

19) Қорытынды

Fail-safe күніне миллиондаған транзакцияларды өңдеу - бұл инварианттар мен тәртіп туралы: ақиқаттың бірыңғай көзі, іспеттес командалар, сағалар және outbox/CDC, кезектегі тәртіп пен дедуп, бақылау және басқарылатын деградация. Қол жеткізу мандаттарын, DR-практикаларды және тұрақты жаттығуларды қосыңыз - және ақша тез және тек бір рет қозғалатын жүйені алыңыз, оқиғалар жоғалмайды, ал трафиктің өсуі мен істен шығулар тосын оқиғалар емес, басқарылатын тәуекелдерге айналады.