DLQ və zəhərli mesajların emalı

Dead Letter Queue (DLQ) - müəyyən bir cəhddən sonra və ya aydın texniki/biznes səbəblərə görə (qeyri-sabit sxem, taymaut, versiya ziddiyyəti və s.) ştat məsləhətçisi tərəfindən idarə olunmayan mesajlar üçün təcrid olunmuş növbə/topikdir. Zəhərli mesaj (poison message) - təkrar emalı ardıcıl olaraq səhv ilə başa çatan və paylayanın sabitliyini təhdid edən qeyd.

DLQ-nin məqsədi: SLO-nu saxlamaq, nasazlığı lokallaşdırmaq, əsas axını bloklamamaq və analiz və təhlükəsiz təkrar oynamaq (redrayva) imkanlarını təmin etməkdir.

1) Zəhərli mesajlar haradan gəlir

Sxemlər/müqavilələr: uyğun olmayan dəyişikliklər, mövcud olmayan məcburi sahələr, səhv növlər.
Biznes validasiyaları: dublikatlar, pozulmuş invariantlar, vaxtı keçmiş hadisələr.
Sifariş və səbəblər: «Create» -dən əvvəl «Update» gəldi, buraxılmış korrelyasiyalar, out-of-order.
İdempotentlik: təkrar emal yan təsirlərə səbəb olur.
Xarici asılılıqlar: məhdud limitlər/vaxtlar, API əlçatmazlığı.
Məlumatlar: yük korrupsiyası, səhv kodlaşdırma, ölçünün aşılması.

2) DLQ-yə göndərmə meyarları

• Konsumer/Worker-də maxAttempts emal aşdı.
• Səhv düzəldilməz (qeyri-retryable) kimi təsnif edilir: qeyri-sabit sxem, kritik resurs olmaması, iş qadağası.
• Deadline mesajı (TTL/expiration).
• Bu açar/tenant üçün circuit breaker və ya admission control siyasəti işlədi.
• Operatorun açıq qərarı (əsas axından əl ilə «eject»).

3) DLQ topologiyaları və nümunələri

Per-queue DLQ: Hər sıra/topik öz DLQ var. Sadə və şəffaf.
Central DLQ (parking lot): mürəkkəb hallar üçün ümumi «park», vahid analiz alətləri üçün əlverişlidir.
DLT (Dead Letter Topic): log yönümlü şinlər üçün (event log) - uğursuzluq səbəbləri olan metadata ilə ayrı bir topik.
Quarantine: əllə analiz üçün sərt giriş və PII sanitariyası ilə karantin bufer.
Shadow-stream: problemli mesajları «kölgə» saxta ilə təhlükəsiz təcrübələr üçün dublyaj.

4) DLQ-ni müşayiət etmək tələb olunan metadata

• Uğursuzluq səbəbi: kod/səhv sinfi, stack/trace id.
• Retray konteksti: 'attempt', 'maxAttempts', 'first _ seen _ ts', 'last _ attempt _ ts'.
• Korrelyasiya: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', partizan açarı.
• Orijinal offset/partition/sequence (lastik üçün) və ya message id.
• Müqavilə/sxem/faydalı yük versiyası.
• Idempotency-key/Request-id (varsa).
• Marşrutlaşdırma mənbəyi: növbə adı/topika, konsumer qrupu.

5) DLQ-dən əvvəl retraj siyasətləri

• Qısa retrasiyalar: 'maxAttempts' 2-5, exponential backoff + jitter, concurrency-da caps.
• Kooperativ backpressure: artan səhvlər ilə rəqabətin azaldılması.
• Səhvlərin təsnifatı: retryable ('5xx', taymaut) vs qeyri-retryable (validasiya, schema mismatch).
• Gecikmiş növbələr (delay queue): 5s → 30s → 2m müvəqqəti uğursuzluqlar üçün.
• Per-key izolyasiya: xüsusi açar «səs-küy» varsa, bütün partişan bloklamayın.

6) Təhlükəsiz redrave (DLQ-dən təkrar çatdırılma)

Redrave, DLQ-dən emala nəzarət olunan mesajların qaytarılmasıdır.

1. Fixin yoxlanılması: yalnız kodu/konfiqurasiyanı/sxemi düzəltdikdən sonra və ya xarici asılılıqları bərpa etdikdən sonra redrayv.

2. İdempotentlik: prosessorlar təkrar davamlı olmalıdır (upsert, effekt-tolurant əməliyyatlar).

3. Deduplikasiya: 'idempotency _ key '/' message _ id '/' business _ key'.

4. Dozaj və pəncərələr: N mesajları batches, redrayv rate-limit, vaxt/partiyalar üzrə «pəncərələr».

5. Lokal validasiya: redrayvdan əvvəl sxemin sürətli yoxlanılması.

6. Prioritet: redrave qida trafikini əvəz etməməlidir (aşağı prioritet worker/ayrı hovuz).

7. Müşahidə: redrayv üçün ayrı-ayrı metriklər və treyslər; nəticə hesabatı (uğur/təkrar DLQ/itki).

7) Çatdırılma semantikası və qaydası

At-least-once - ən çox yayılmış rejim: idempotentlik və duplikasiya lazımdır.
At-most-once - DLQ söndürülə bilər; zərər riski. Yalnız icazə verilən itkilər zamanı istifadə edin.
Exactly-once (effektiv): biznes anbarında əməliyyatlar və dedups ilə əldə edilir; bahalı və spesifik.
Sifariş: DLQ adətən xüsusi açar/partiya üçün qaydanı pozur. Sifariş kritik olarsa, açar və ardıcıl olaraq yenidən oxuyun.

8) Sxemlər, müqavilələr və validasiya

Schema registry/müqavilələr: aydın versiyalaşdırma, backward/forward uyğunluğu ilə təkamül.
Girişdə validasiya: ağır addımlar əvvəl JSON Schema/Protobuf/Avro vasitəsilə ucuz yoxlama.
Uyğunsuzluq siyasəti: «sındırıcı» sahədə - dərhal 'SCHEMA _ INCOMPATIBLE' kodu ilə DLQ-də.
Redaction PII: DLQ-də yalnız lazım olanları saxlayın; həssas sahələr maska.

9) İdempotentlik və duplikasiya

Idempotency-key: prodüserdə "biznes mənası 'ndan (tenant + entity + operation + ts-bucket) formalaşdırın.
Dedup jurnalları: TTL ilə son 'N' açarları saxlayın; əməliyyatın «effekti» yadda saxlayın.
Upsert/merge: məhdudiyyətsiz «insert-only» çəkinin.
Sayd effektləri: xarici zənglər üçün - zəng etməzdən əvvəl "təkrarlama 'nı qeyd edin və yoxlayın.

10) Müşahidə və SLO

• DLQ rate (msg/s), mesajların payı, DLQ-də orta/orta «yaş».
• Redrayv müvəffəqiyyəti (%), təkrar DLQ payı.
• Səbəblərin təsnifatı: schema, validation, timeout, dependency, unknown.
• p95/p99 redrayve vs əsas axını emal gecikmə.
• DLQ ölçüsü, daşınma riski.

• Məcburi etiketlər: 'message _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• «DLQ filialının» izlənməsi: mənbədən yenidən müvəffəqiyyətə qədər.

• Uğurla işlənmiş mesajların payı T dəqiqədə X% ≥.
• DLQ case üçün araşdırma və düzəliş vaxtı ≤ Y saat.
• Maksimum mesaj «yaş» DLQ ≤ Z saat (alert ilə).

11) Təhlükəsizlik və uyğunluq

Ən kiçik imtiyazlar prinsipi üzrə giriş: redrave - yalnız operatorlara/playbuklara.
Audit: Kimlər və nə vaxt meta məlumatların redrayv/silinməsi/redaktəsini tetiklədi.
Sanitariya: Mərkəzi DLQ-yə köçürüldükdə əlavə PII/sirləri silin.
Retention: ayrı saxlama müddəti və DLQ üçün silinmə siyasəti.

12) Multi-tenant

Tags 'tenant _ id/plan': limitləri, redrayv prioritetləri, hesabatları ayırd edin.
Per-tenant DLQ və ya partiyalar: «səs-küylü» müştəri ümumi DLQ-ni vurmamalıdır.
Billing/kvotalar: DLQ həcmi və usage redrayv dəyəri nəzərə alınır.

13) Konfiqurasiya şablonları (nümunə)

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) Əməliyyat pleybukları (runbooks)

1. Anormal DLQ artımı: throttling prod-müştəri daxil edin, top səbəbləri təhlil edin, relizləri/sxemləri yoxlayın.
2. Schema mismatch: sxem geri/fiksasiya, adapter miqrasiyası, yoxlandıqdan sonra redrive.
3. Xarici asılılıq əlçatmazdır: retraj fasiləsi, bərpa edildikdən sonra delay-növbə, redrive.
4. redrave sonra təkrar DLQ: «kölgə» prosessor/simulyator yandırmaq, idempotent yoxlamaq, batch daraltmaq.
5. DLQ daşması: arxiv-storage evakuasiya, açar/səbəblərə görə seçici redrave daxil.

15) Test və xaos

Enjeksiyon səhvlər: schema-break, validation, taymaut, 1-on-N «yapışqan» səhvlər.
Kütləvi redrave: Dozaj və prod təsiri yoxlanılır.
Out-of-order ardıcıllığı: ensure düzgün açar emalı.
Faydalı yük korrupsiyası: validasiya və təhlükəsiz uğursuzluq.
Redrave worker düşdükdən sonra bərpa: batch əməliyyatlarının idempotentliyi.

16) Tipik səhvlər

DLQ → meta məlumatların olmaması səbəbləri klasterləşdirmək və təhlükəsiz redrayv etmək mümkün deyil.
Limitsiz kütləvi redrayv → prodakşenin təkrar deqradasiyası.
No idempotentity/deadup → Duble və yan təsirləri.
Sanitariya olmadan mərkəzi DLQ PII qarışdırın.
Mesajların təkamülü zamanı sxemlərin/müqavilələrin olmaması → «sürprizlər».
Tenant/açar partiyasız yeganə ümumi DLQ.
Qeyri-retryable səhvlər üçün erkən DLQ əvəzinə sonsuz retrajlar.

17) Sürətli reseptlər

Adi iş axını: 3-4 cəhd, jitter ilə eksponensial backoff, səhvlərin erkən təsnifatı, tam metadata ilə DLQ.
Kritik hadisələr (ödəniş): ciddi idempotentlik, qısa müddət, minimum cəhd, sürətli DLQ və əl təhlili.
Fix sonra kütləvi redrive: kiçik batches (100-500), rate-limit, ayrı hovuz worker, müvəffəqiyyət monitorinqi> 95% sürət artmadan əvvəl.
Multi-tenant: redrayv üçün per-tenant limitlər, DLQ-nin ən yaxşı müştəri generatorları haqqında hesabat.

Nəticə

DLQ «zibil qutusu» deyil, nəzarət olunan etibarlılıq dövrəsidir. Dəqiq vurma qaydaları, zəngin meta məlumatlar, idempotentlik və deuplikasiya, təhlükəsiz dozalı redrayv, sxemlərin nizam-intizamı və müşahidə edilməsi SLO üçün təhlükədən zəhərli mesajları idarə olunan mühəndislik prosesinə çevirir - başa düşülən playbook, proqnozlaşdırılan xərclər və istifadəçilərə minimum təsir ilə.