Kuniga millionlab tranzaksiyalarning fail-safe jarayonini qanday qurish kerak

Maqolaning to’liq matni

💡 Fintex/qimor va turdosh tarmoqlarning oziq-ovqat va platforma jamoalari uchun texnik material. O’yinga chaqirish emas. «Tranzaksiyalar» deganda pul/hisob operatsiyalari (hisobdan chiqarish, o’tkazish, o’tkazish, settlment, qaytarish) tushuniladi.

1) Tranzaksiyalar uchun fail-safe nimani anglatadi

Fail-safe - bu har qanday buzilish holati pul va ma’lumotlarni yo’qotmasdan xavfsiz to’xtashga yoki kompensatsiya qilinadigan holatga olib kelganda. Maqsadlar:

«Ikki marta debet/kredit» = 0.
Yoʻqotilgan tranzaksiyalar/hodisalar = 0.
Latentlik/yetkazib berish bo’yicha bashorat qilinadigan SLO, aniq degradatsiya rejimlari va DR.

Asosi - pul invariantlari (balansning haqiqati bir joyda), idempotentlik, voqealarni kelishib yetkazish.

2) Arxitektura prinsiplari (qisqacha)

1. Single source of truth: balans va buxgalteriya - Ledger/Walletda. Xizmatlar pul emas, balki jarayon holatini ushlab turadi.

2. Idempotency everywhere: barcha «yozuvlar» operatsiyalari’Idempotency-Key’ni qabul qiladi; takrorlash natijani qaytaradi.

3. Etkazib berish kafolati bilan hodisa: outbox/CDC, navbatlar, DLQ, dedup.

4. Dastalar va kompensatsiyalar, «qo’lda tuzatishlar» emas.

5. Back-pressure va ustuvorliklar: tizim sekinlashadi, lekin qulamaydi.

6. Andoza koʻrinish: tuzilgan loglar, treysing, metriklar.

7. Ko’p mintaqa va DR: aktiv-aktiv/aktiv-passiv, muntazam mashg’ulotlar.

3) Referens-topologiya


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

Asosiy joylar: Outbox (jamoaning yadroviy yozuvi va voqeaning «loyihalari»), Publisher (bir marta yetkazib berish), Consumers (idempotent, dedup-kaliti bilan), DLQ/Replay (nazorat qilinadigan takrorlash).

4) Pul invariantlari va kelishuv

Balans bo’yicha haqiqat - Ledger (ACID, seriyali tranzaksiyalar yoki hisobni qat’iy tartibga solish).

Pul buyruqlari:’debit’,’credit’,’hold’,’commit’,’rollback’- idempotentdir.

Kombinatsiyalangan jarayonlar quyidagi dostonlar sifatida quriladi:

’authorize → settle → credit’ (depozit/settlment),’request → submit → settled/failed’(to’lov/chiqarish),’refund/void’(kompensatsiya).
Ledger’ni chetlab oʻtish uchun toʻgʻridan-toʻgʻri balans tuzatishlari yoʻq.

5) Idempotentlik: kalitlar dizayni

Kalit biznes operatsiyani aniq identifikatsiya qilishi kerak:

`bet_id+amount+currency`, `payment_intent+capture_id`, `payout_id`, `chain_txid`.
Natijani kalit bilan saqlash (response cache). Bir xil kalit bilan takrorlash → bir xil body/maqom.
Nomuvofiqlikni nazorat qiling: boshqa summa bilan bir xil kalit →’IDEMPOTENCY _ MISMATCH’.

6) Navbatlar, tartib va dedup

Exactly-once effektlariga transport orqali emas, balki idempotent konsumerlari + dedup saqlash (LRU/Redis/DB c TTL) orqali erishiladi.

Kalit tartibini saqlang (partition key =’account _ id/round _ id/player _ id’).

«Xilma-xil» kalitlar uchun - state machine per entity (state machine per entity).

DLQ majburiy: N urinishlardan so’ng - izolyatsiya qilingan mavzuda o’qish mumkin bo’lgan sababga ko’ra.

7) Outbox/CDC: nima uchun voqealar «yo’qolmaydi»

Bitta tranzaksiya doirasida servisning DBsida biznes o’zgarishi va outbox-dagi yozuvni yozib olamiz.

Alohida publisher outbox oʻqiydi va tasdiqlangan shina orqali eʼlon qiladi.

Muqobil - CDC (Change Data Capture) DB (Debezium/log replikatsiyasi) darajasida.

Tranzaksiyadan oldin hech qanday «voqealar loglari» yo’qotishlar manbai hisoblanadi.

8) Back-pressure va ustuvorliklar

Token-baketlar va kirish kvotalari (per tenant/brand/region).

Ustuvor navbatlar: pul yo’llari promo/telemetriyadan yuqori.

Ortiqcha yuklashda:’no new sessions/requests’rejimlari, ikkilamchi fichlarni muzlatish, yadroni saqlash.

Avto-degradatsiyalar: fon vazifalari chastotasini qisqartirish, tanqidiy vorkerlarni dinamik ravishda kengaytirish.

9) Ko’p mintaqali barqarorlik

API va navbatlar uchun aktiv-aktiv, lokal Ledger (yoki mintaqa/valyuta bo’yicha sharding bilan global).

Data residency: pul/PII/jurnallar aniq qoidalarsiz krosslanmaydi.

Hodisalarning mintaqalararo replikatsiyasi «region» belgisi qo’yilgan asinxron.

RPO/RTO: RPO ≤ 5 daqiqa, RTO ≤ 30 daqiqa o’tkazing; muntazam ravishda tekshirib turing.

10) SLO/SLI va dashbordlar

Taxminlar (misol):

p95’authorize/debit/credit’<150-300 ms (ichki yo’l).
p95 end-to-end «komanda → shina hodisasi» <1-2 s.
Vebxuk/tashqi voqealarni yetkazib berish p99 <5 min.
«Yo’qotilgan/dublyaj qilingan tranzaksiyalar» = 0 (kontrakt tekshiruvlari).

Metriklar: latency p50/p95/p99, error-rate (4xx/5xx/business), consumer/queue lag, retry storms, settle lag, webhook lag, DLQ o’lchami, chastotasi’IDEMPOTENCY _ MISMATCH’.

11) Kuzatuv va audit

JSON’trace _ id’,’idempotency _ key’, biznes-ID, xato kodlari bilan tuzilgan JSON loglari.

OpenTelemetry: treysing HTTP/gRPC/DB/shinalar, span sag.

WORM-audit: o’zgarmas tanqidiy o’zgarishlar jurnallari (limitlar, kalitlar, promo/jekpot konfiguralari).

PII/sirlarni kamuflyaj qilish, mintaqaviy baketalar, RBAC/ABAC.

12) Ishonchlilikni sinovdan o’tkazish

Kontrakt testlari: takrorlash/dublikatlar, out-of-order, idempotentlik, dedup.

Yuklama: cho’qqilar profili (x10), navbatlar va DB barqarorligi.

Xaos-keyslar: Ledger/hamyon yiqilishi, navbatlar/mintaqalar, CDC kechikishlari, retraylarning «bo’roni».

Game Days: DR va hodisalarning muntazam mashqlari, MTTR o’lchovlari.

13) Omborlar va ma’lumotlar

OLTP pul bilan: tranzaksion DB (RPO ≈ 0), qatʼiy indekslar, tanqidiy mohiyatlar boʻyicha seriyalanadigan darajalar.

Kesh (Redis) - faqat tezlashtirish uchun, «haqiqat» uchun emas. TTL + jitter, cache stampede himoyasi.

OLAP/DWH - hisobotlar/tahlillar uchun. CDC/shina oqimlari, OLTP yuklamasdan.

Ma’lumotlar sxemalari versiyalashtiriladi; (expand/contract).

14) Retraylarni orkestrlash

Eksponensial backoff + jitter, RPC dagi muddatlar/vaqt.

Har bir qatlamda idempotent takrorlash (mijoz → xizmat → isteʼmolchi).

Retrajda kvotalar, «bo’ronlar» dan himoyalanish (circuit breaker, hedged requests).

DLQ dan faqat «xavfsiz» oynalarga, tezlik chegarasi bilan replay.

15) Transport xavfsizligi

mTLS hamma joyda S2S, qisqa yashaydigan tokenlar (CC OAuth2), vebxuklar uchun jismlarning imzolari (HMAC/EdDSA).

Vault/HSM sirlari, rotatsiya, per brand/region kalitlari.

Least privilege siyosati, qo’lda ishlash uchun «to’rt ko’z».

16) Namunaviy kontraktlar (parchalar)

Idempotent debet jamoasi


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" }
(takrorlash → xuddi shu javob)

Outbox voqeasi

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) Chek-varaqlar

Platforma/operator

Haq - bitta Ledger; aylanma yo’llar yo’q.
’Idempotency-Key’bilan barcha write-operatsiyalar; Javob kalitda saqlanadi.
Barcha domen yozuvlari, DLQ va boshqariladigan replay uchun Outbox/CDC.
Ustuvor navbatlar, back-pressure, degradatsiya rejimlari.
Partition-keys biznes kalitlari boʻyicha tanlangan; iste’molchilar idempotentdir.
SLO-dashbordlar, OpenTelemetry, WORM-audit.
Muntazam DR/xaoc-mashqlar, kontrakt/yuklash testlari.
Data residency, shifrlash, Vault/HSM, kalitlarni aylantirish.

Provayderlar/integratsiyalar

’Trace-Id ’/’ Idempotency-Key’ni yuboraman, qayta yetkazib berishga tayyorman.
Vebxuklar imzolangan va duplizatsiya qilinmoqda.
Sxemalar/kontraktlarning versiyalariga rioya qilinadi (semver, deprecation).

18) Qizil bayroqlar (anti-patternlar)

Balans Ledger’da buyruqsiz vebxuk boʻyicha oʻzgaradi.

Idempotentlik yo’qligi → ikki baravar hisobdan chiqarish/kreditlar.

Outbox/CDC’ni chetlab oʻtish.

Back-pressure boʻlmagan monolit: trafikning eng yuqori choʻqqisi hamma narsani yoʻqotadi.

OLTP va hisobotlarni aralashtirish: BI jangovar ma’lumotlarni uradi.

DLQ/replay yo’qligi; xatolarni «jimgina» yutish.

PII/pul mintaqaviy izolyatsiyasi mavjud emas; bir nechta brendlar uchun umumiy kalitlar.

DBdagi balanslar/maqomlarni qo’lda tuzatish.

19) Jami

Fail-safe kuniga millionlab tranzaksiyalarni qayta ishlash - bu invariantlar va intizom haqida: yagona haqiqat manbai, idempotent buyruqlar, dostonlar va outbox/CDC, navbatda turish tartibi va dedup, kuzatish va boshqariladigan degradatsiyalar. Kirish mandatlari, DR-amaliyotlar va muntazam mashqlarni qo’shing - va pul tez va faqat bir marta harakatlanadigan tizimni oling, voqealar yo’qolmaydi, trafikning o’sishi va nosozliklar kutilmagan hodisalar emas, balki boshqariladigan xatarlarga aylanadi.