DLQ va zaharli xabarlarni qayta ishlash

Dead Letter Queue (DLQ) - belgilangan urinishlardan so’ng yoki aniq texnik/biznes sabablarga ko’ra (nolid sxema, taymaut, versiyalar to’qnashuvi va boshqalar) shtatdagi konsumer tomonidan qayta ishlanmaydigan xabarlar uchun izolyatsiya qilingan navbat/topik. Zaharli xabar (poison message) - qayta ishlanishi xato bilan tugaydigan va payplaynning barqarorligiga tahdid soladigan yozuv.

DLQning maqsadi: SLOni saqlash, nosozlikni mahalliylashtirish, asosiy oqimni blokirovka qilmaslik va tahlil qilish va xavfsiz takrorlash imkoniyatlarini kafolatlashdir.

1) Zaharli xabarlar qayerdan keladi

Sxemalar/kontraktlar: mos kelmaydigan o’zgarishlar, mavjud bo’lmagan majburiy maydonlar, noto’g "ri turlar.
Biznes-validatsiyalar: dublikatlar, buzilgan invariantlar, muddati o’tgan voqealar.
Tartib va sabablar: «Create» dan oldin «Update» keldi, o’tkazib yuborilgan korrelyatsiyalar, out-of-order.
Idempotentlik: qayta ishlash nojo’ya ta’sirlarni keltirib chiqaradi.
Tashqi qaramliklar: cheklangan limitlar/taymautlar, API ning mavjud emasligi.
Ma’lumotlar: foydali yuk korrupsiyasi, noto’g "ri kodlash, o’lchamlarni oshirib yuborish.

2) DLQga jo’natish mezonlari

• Konsumer/vorkerda ishlash uchun maxAttempts ortiqcha.
• Xato tuzatib bo’lmaydigan (non-retryable) deb tasniflangan: noto’g’ri sxema, tanqidiy resurs yo’qligi, biznes taqiq.
• Xabar muddati tugadi (TTL/expiration).
• Ushbu kalit/tenant uchun circuit breaker yoki admission control siyosati ishladi.
• Operatorning aniq qarori (asosiy oqimdan qo’lda «eject»).

3) DLQ topologiyalari va patternlari

Per-queue DLQ: har bir navbatning/topikning oʻziga xos DLQ mavjud. Oddiy va shaffof.
Central DLQ (parking lot): murakkab holatlar uchun umumiy «parking», yagona tahlil vositalari uchun qulay.
DLT (Dead Letter Topic): log-yo’naltirilgan shinalar uchun (event log) - rad etish sabablari meta-ma’lumotlari bo’lgan alohida topik.
Quarantine: qo’lda tahlil qilish uchun qattiq kirish va PII sanitariyasi bo’lgan karantin buferi.
Shadow-stream: xavfsiz fik tajribalar uchun muammoli xabarlarni «soyada» takrorlash.

4) DLQni kuzatib borishi shart bo’lgan meta ma’lumotlar

• Xato sababi: kod/sinf xatosi, stack/trace id.
• Retray konteksti:’attempt’,’maxAttempts’,’first _ seen _ ts’,’last _ attempt _ ts’.
• Korrelyatsiya:’trace _ id’,’span _ id’,’tenant _ id’,’entity _ id’, partilizatsiya kaliti.
• Original offset/partition/sequence (log shinalari uchun) yoki message-id.
• Foydali yuklamaning kontrakti/sxemasi/versiyasi.
• Idempotency-key/Request-id (agar mavjud bo’lsa).
• Yo’nalish manbai: navbat/topika nomi, konsumer guruhi.

5) DLQgacha retraj siyosati

• Qisqa retralar:’maxAttempts’2-5, exponential backoff + jitter, caps on concurrency.
• Kooperativ backpressure: xatolar koʻpayganda raqobatni kamaytirish.
• Xatolar tasnifi: retryable (’5xx’, taymaut) vs non-retryable (validatsiya, schema mismatch).
• Kechiktirilgan navbatlar (delay queue): 5s → 30s → 2m.
• Per-key izolyatsiya: agar ma’lum bir kalit «shovqin» qilsa, partishenni to’sib qo’ymang.

6) Xavfsiz redrayv (DLQ dan qayta yetkazib berish)

Redrave - bu DLQ dan xabarlarni qayta ishlashga boshqariladigan qaytarishdir.

1. Fixni tekshirish: faqat kodni/konfiguratsiyani/sxemani tuzatgandan keyin yoki tashqi bogʻliqliklar tiklangandan keyin redrayv.

2. Idempotentlik: qayta ishlovchilar takrorlashga chidamli bo’lishi kerak (upsert, effekt-tolurant operatsiyalar).

3. Deduplikatsiya:’idempotency _ key ’/’ message _ id ’/’ business _ key’.

4. Dozalash va oynalar: N xabarlar bo’yicha batches, redrayv bo’yicha rate-limit, vaqt/partiyalar bo’yicha «derazalar».

5. Lokal validatsiya: redrayv oldidan sxemani tezda tekshirish.

6. Ustuvorlik: redrayv oziq-ovqat trafigini siqib chiqarmasligi kerak (past ustuvorlik/alohida hovuz).

7. Kuzatilishi: redrayv uchun alohida metrika va treyslar; natijalar to’g "risidagi hisobot (muvaffaqiyat/takroriy DLQ/yo’qotish).

7) Yetkazib berish semantikasi va tartibi

At-least-once - eng ko’p uchraydigan rejim: idempotentlik va deduplikatsiya zarur.
At-most-once - DLQ o’chirilishi mumkin; yo’qotish xavfi. Faqat mumkin boʻlgan yoʻqotishlarda foydalaning.
Exactly-once (samarali): biznes omboriga tranzaksiyalar va dedup orqali erishiladi; qimmat va o’ziga xos.
Tartib: DLQ odatda aniq kalit/partiya uchun tartibni buzadi. Agar tartib tanqidiy bo’lsa, uni kalit bo’yicha va izchil tahrirlang.

8) Sxemalar, kontraktlar va validatsiya

Schema registry/kontraktlar: aniq versiyalash, backward/forward-mosligi bilan evolyutsiya.
Kirish validatsiyasi: qiyin qadamlar oldidan JSON Schema/Protobuf/Euro orqali arzon tekshirish.
Nomuvofiqlik siyosati: «buzuvchi» maydonda - darhol «SCHEMA _ INCOMPATIBLE» kodi bilan DLQda.
Redaction PII: DLQ’da faqat kerakli narsalarni saqlang; sezgir maydonlarni yashiring.

9) Idempotentlik va deduplikatsiya

Idempotency-key: prodyuserda «biznes ma’nosi» (tenant + entity + operation + ts-bucket) dan shakllantiring.
Dedup jurnallar: TTL bilan oxirgi’N’kalitlarni saqlang; amalning «effektini» eslab qoling.
Upsert/merge: cheklovlarsiz «insert-only» dan qoching.
Sayd effektlari: Tashqi qo’ng’iroqlar uchun - qo’ng’iroqdan oldin «takrorlash» ni jurnalga kiriting va tekshiring.

10) Kuzatuv va SLO

• DLQ rate (msg/s), xabarlar ulushi, DLQdagi o’rtacha/median «yosh».
• Redrayvning muvaffaqiyati (%), takroriy DLQ ulushi.
• Sabablar tasnifi: schema, validation, timeout, dependency, unknown.
• p95/p99 asosiy oqimni qayta ishlashning latentligi vs redrayvda.
• DLQ miqdori, to’lib ketish xavfi.

• Majburiy teglar:’message _ id’,’entity _ id’,’tenant _ id’,’attempt’,’reason’,’redrive _ batch _ id’.
• «DLQ» shoxobchasi: manbadan qaytadan muvaffaqiyatgacha.

• Muvaffaqiyatli qayta ishlangan xabarlar ulushi ≥ T daqiqada%.
• DLQ-keysni tekshirish va tuzatish vaqti ≤ Y soat.
• Xabarning eng katta «yoshi» DLQ ≤ Z soat (alert bilan).

11) Xavfsizlik va muvofiqlik

Eng kam imtiyozlar tamoyili bo’yicha foydalanish: redrayv - faqat operatorlar/pleybuklarga.
Audit: meta ma’lumotlarni tahrirlash/o’chirish/tahrirlash.
Sanitariya: central DLQ ga koʻchirilganda ortiqcha PII/sirlarni olib tashlang.
Retention: DLQ uchun alohida saqlash muddatlari va olib tashlash siyosati.

12) Ko’p tenantlik

’tenant _ id/plan’ teglari: limitlar, redrayv ustuvorliklari, hisobotlar.
«Shovqinli» mijoz umumiy DLQni to’plamasligi uchun.
Billing/kvotalar: DLQ hajmini va redrayv qiymatini hisobga oling usage.

13) Konfiguratsiya shablonlari (misol)

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14) Operatsion pleybuklar (runbooks)

1. DLQ ning g’ayritabiiy o’sishi: prod-konsumerni ishga tushirish, top-sabablarni tahlil qilish, relizlarni/sxemalarni tekshirish.
2. Schema mismatch: sxemani qaytarish/tuzatish, adapter migratsiyasi, tekshirilgandan keyin redrive.
3. Tashqi bogʻliqlik mavjud emas: retraylarni toʻxtatish, delay-navbatni yoqish, tiklangandan keyin redrive.
4. Qayta ishlangan DLQ: «soyali» ishlov beruvchi/simulyatorni yoqish, idempotentlikni tekshirish, batchni toraytirish.
5. DLQni to’ldirish: arxiv-storage-ga evakuatsiya qilish, kalit/sabablarga ko’ra selektiv tahrirni kiritish.

15) Test va tartibsizlik

Xatolarni in’ektsiya qilish: schema-break, validatsiya, taymautlar, 1-N «yopishqoq» xatolar.
Ommaviy redrayv: dozalash va prodga ta’sirini tekshirish.
Out-of-order ketma-ketligi: ensure kalitlar boʻyicha toʻgʻri ishlov berish.
Foydali yuk korrupsiyasi: validatsiya va xavfsiz rad etish.
Redrayv-vorker yiqilganidan keyin tiklanish: batch-operatsiyalarning idempotentligi.

16) Tipik xatolar

DLQ → da meta ma’lumotlar yo’qligi sabablarni klaster qilib bo’lmaydi va xavfsiz ravishda qayta yozib bo’lmaydi.
Limitsiz ommaviy redrayv → prodakshenning qayta degradatsiyasi.
Idempotentlik/daduplik yo’q → dubli va nojo’ya ta’sirlar.
PII ni sanitariyasiz central DLQga aralashtirish.
Xabarlar evolyutsiyasida sxemalar/shartnomalar yo’qligi → «kutilmagan hodisalar».
Tenant/kalitlar bo’yicha partiyalashmagan yagona umumiy DLQ.
Noto’g’ri xatolar uchun erta DLQ o’rniga cheksiz retrajlar.

17) Tezkor retseptlar

Oddiy biznes oqimi: 3-4 ta urinish, jitter bilan eksponensial backoff, xatolarning erta tasnifi, to’liq meta ma’lumotlar bilan DLQ.
Tanqidiy hodisalar (to’lov): qat’iy idempotentlik, qisqa taymautlar, minimal urinishlar, tezkor DLQ va qo’lda tahlil.
Small batches (100-500), rate-limit, alohida vorker puli, tezlikni oshirishdan oldin 95% muvaffaqiyat monitoringi.
Multi-tenant: redrayv uchun per-tenant limitlar, DLQ top-mijozlar-generatorlari bo’yicha hisobot.

Xulosa

DLQ - bu «axlat qutisi» emas, balki nazorat qilinadigan ishonchlilik konturidir. Aniq zarba berish qoidalari, boy meta ma’lumotlar, idempotentlik va deduplikatsiya, xavfsiz dozalangan redrayv, sxemalar tartibi va kuzatish qobiliyati zaharli xabarlarni SLO uchun tahdiddan boshqariladigan muhandislik jarayoniga aylantiradi - tushunarli pleybuklar, prognoz qilingan xarajatlar va foydalanuvchilarga minimal ta’sir ko’rsatish.