DLQ және улы хабарламаларды өңдеу

Dead Letter Queue (DLQ) - бұл берілген әрекеттер санынан кейін немесе анық техникалық/бизнес себептері бойынша штаттық консьюмермен өңделмеген хабарламаларға арналған оқшауланған кезек/топик (бейвалидті схема, таймаут, нұсқалар қақтығысы және т.б.). Улы хабар (poison message) - қайта өңделуі тұрақты түрде қатемен аяқталатын және пайплайн тұрақтылығына қауіп төндіретін жазба.

DLQ мақсаты: SLO-ны сақтау, ақаулықты оқшаулау, негізгі ағынды бұғаттауға жол бермеу және талдау және қауіпсіз қайта шығару (редрайва) мүмкіндіктеріне кепілдік беру.

1) Улы хабарлар қайдан алынады

Схемалар/келісімшарттар: үйлеспейтін өзгерістер, жоқ міндетті өрістер, дұрыс емес типтер.
Бизнес-валидациялар: телнұсқалар, бұзылған инварианттар, мерзімі өткен оқиғалар.
Тәртібі мен себептері: «Update» «Create» дейін келді, жіберіп алған корреляциялар, out-of-order.
Теңсіздік: қайта өңдеу жанама әсерлерді тудырады.
Сыртқы тәуелділіктер: шектеулі лимиттер/таймауттар, API қолжетімсіздігі.
Деректер: пайдалы жүктеме сыбайлас жемқорлығы, дұрыс кодталмаған, мөлшерден асып кеткен.

2) DLQ-ға жіберу критерийлері

• Консьюмерде/воркерде өңдеу maxAttempts асып кетті.
• Қате түзетілмейтін (non-retryable) ретінде жіктелген: қате схема, сындарлы ресурстың болмауы, бизнес-тыйым салу.
• Хабарламаның deadline (TTL/expiration) аяқталды.
• Осы кілт/тенант үшін circuit breaker немесе admission control саясаты жұмыс істеді.
• Оператордың айқын шешімі (негізгі ағыннан қол «eject»).

3) DLQ топологиялары мен паттерндері

Per-queue DLQ: әрбір кезек/топиктің өз DLQ бар. Қарапайым және ашық.
Central DLQ (parking lot): күрделі жағдайлар үшін жалпы «паркинг», бірыңғай талдау құралдары үшін ыңғайлы.
DLT (Dead Letter Topic): лог-бағдарлы шиналар үшін (event log) - істен шығу себептерінің метадеректері бар жеке топик.
Quarantine: қолмен талдауға арналған қатаң қолжетімділігі және PII-санитариясы бар карантиндік буфер.
Shadow-stream: проблемалық хабарларды «көлеңкеге» көшіру.

4) DLQ сүйемелдеуге міндетті метадеректер

• Бас тарту себебі: код/қате класы, stack/trace id.
• Контекст ретрайлері: 'attempt', 'maxAttempts', 'first _ seen _ ts', 'last _ attempt _ ts'.
• Корреляция: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', партияландыру кілті.
• Түпнұсқа offset/partition/sequence (логтық шиналар үшін) немесе message-id.
• Пайдалы жүктеме келісімшарты/схемасы/нұсқасы.
• Idempotency-key/Request-id (бар болса).
• Бағыттау көзі: кезек/топик атауы, консьюмер тобы.

5) DLQ дейінгі ретрациялардың саясаты

• Консьюмердің қысқа ретрайлері: 'maxAttempts' 2-5, exponential backoff + джиттер, caps concurrency.
• Кооперативтік backpressure: қателердің өсуі кезінде бәсекелестіктің азаюы.
• Қателер жіктелімі: retryable ('5xx', таймаут) vs non-retryable (валидация, схема mismatch).
• Кейінге қалдырылған кезектер (delay queue): 5s → 30s → 2m уақытша ақаулықтар үшін.
• Per-key оқшаулау: Егер нақты кілт «шулы» болса, барлық топтаманы бұғаттамаңыз.

6) Қауіпсіз редрайв (DLQ-дан қайта жеткізу)

Редрайв - бұл DLQ хабарын өңдеуге бақыланатын қайтару.

1. Фиксті тексеру: кодты/конфигурацияны/схеманы түзеткеннен кейін немесе сыртқы тәуелділіктерді қалпына келтіргеннен кейін ғана редрайв.

2. Теңсіздік: өңдегіштер қайталануға төзімді болуы тиіс (upsert, әсерлі-толурантты операциялар).

3. Дедупликация: 'idempotency _ key '/' message _ id '/' business _ key' бойынша.

4. Дозалау және терезелер: хабарламаның N бойынша batches, редрайвқа rate-limit, уақыт/партия бойынша «терезелер».

5. Жергілікті валидация: редрайвтың алдындағы схеманы жылдам тексеру (бұрынғы валидті емес кейстердің reject).

6. Басымдық: редрайв азық-түлік трафигін ығыстырмауы тиіс (воркерлердің төмен басымдығы/жеке пул).

7. Бақылау қабілеті: редрайвқа арналған жеке метриктер мен трестер; нәтижелер туралы есеп (табыс/қайталанған DLQ/жоғалту).

7) Жеткізу семантикасы және тәртібі

At-least-once - ең жиі қолданылатын режим: демпотенттілік және дедупликация қажет.
At-most-once - DLQ ажыратылуы мүмкін; жоғалту тәуекелі. Жарамды жоғалтулар кезінде ғана пайдаланыңыз.
Exactly-once (тиімді): бизнес-қоймада транзакциялармен және дедуппен қол жеткізіледі; қымбат және ерекше.
Тәртіп: DLQ әдетте нақты кілт/партия үшін тәртіпті бұзады. Егер тәртіп сыни болса, кілт бойынша және дәйекті түрде қайта қараңыз.

8) Схемалар, келісімшарттар және валидация

Schema registry/келісімшарттар: нақты нұсқалау, backward/forward-үйлесімділігімен эволюция.
Кіре берістегі валидация: ауыр қадамдар алдында JSON Schema/Protobuf/Euro арқылы арзан тексеру.
Сәйкессіздік саясаты: «сындыру» өрісі кезінде - дереу 'SCHEMA _ INCOMPATIBLE' кодымен DLQ-де.
Redaction PII: DLQ-де тек қажетті нәрселерді сақтаңыз; сезімтал өрістерді бүркемелеңіз.

9) Идемпотенттілік және дедупликация

Idempotency-key: продюсерде «бизнес-мағынадан» (tenant + entity + operation + ts-bucket) қалыптастырыңыз.
Дедуп журналдары: TTL бар соңғы 'N' кілттерін сақтаңыз; әрекеттің «эффектін» есте сақтаңыз.
Upsert/merge: шектеусіз «insert-only» дегеннен аулақ болыңыз.
Сайд эффекттері: Сыртқы шақырулар үшін - шақырудың алдында «қайталауды» журналдап, тексеріңіз.

10) Бақылау және SLO

• DLQ rate (msg/s), хабарламалар үлесі, DLQ-дағы орташа/медианалық «жас».
• Редрайвтың табысы (%), қайталама DLQ-үлес.
• Себептерді жіктеу: schema, validation, timeout, dependency, unknown.
• p95/p99 негізгі ағынды өңдеудің латенттілігі vs редрайвте.
• DLQ мөлшері, толу тәуекелі.

• Міндетті тегтер: 'message _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• DLQ тармағын іздеу: қайнар көзден табысқа дейін.

• Сәтті өңделген хабарламалардың үлесі T минут ішінде X% ≥.
• DLQ-кейс үшін тексеру және түзету уақыты ≤ Y сағат.
• Хабарламаның ең үлкен «жасы» DLQ ≤ Z сағатта (алертпен).

11) Қауіпсіздік және сәйкестік

Ең аз артықшылықтар қағидаты бойынша қол жеткізу: редрайв - тек операторларға/плейбуктарға.
Аудит: метадеректерді редрайв/жою/редакциялауды кім және қашан триггерледі.
Санитария: central DLQ-ге ауыстыру кезінде артық PII/құпияларды жойыңыз.
Retention: DLQ үшін бөлек сақтау мерзімдері және жою саясаты.

12) Мульти-тенанттық

Тегтер 'tenant _ id/plan': лимиттерді, редрайвтың басымдықтарын, есептерді ажыратыңыз.
Пер-тенантты DLQ немесе партия: «шулы» клиент ортақ DLQ ойнатпауы үшін.
Биллинг/квоталар: DLQ көлемін және usage-дегі редрайваның құнын ескеріңіз.

13) Конфигурациялық үлгілер (мысал)

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) Операциялық плейбуктер (runbooks)

1. DLQ аномалды өсуі: throttling прод-консьюмерін қосу, жоғарғы себептерді талдау, релиздерді/схемаларды тексеру.
2. Schema mismatch: схеманы кері қайтару/бекіту, адаптердің көшуі, тексеруден кейін redrive.
3. Сыртқы тәуелділік қол жетімді емес: ретрациялардың үзілісі, delay-кезегін қосу, қалпына келтірілгеннен кейін redrive.
4. Қайта өңдеуден кейін DLQ: «көлеңкелі» өңдегішті/симуляторды қосу, ұқсастығын тексеру, batch тарылту.
5. DLQ толуы: мұрағат-storage көшіру, кілттер/себептер бойынша селективті редрайды қосу.

15) Тестілеу және хаос

Қателерді инъекциялау: schema-break, валидация, таймауттар, 1-на-N «жабысқақ» қателер.
Жаппай редрайв: дозалауды және өнімге әсерін тексеру.
Out-of-order жүйелілігі: ensure кілттер бойынша дұрыс өңдеу.
Пайдалы жүктеме сыбайлас жемқорлығы: валидация және қауіпсіз бас тарту.
Редрайв-воркер құлағаннан кейін қалпына келтіру: batch-операциялардың іспеттілігі.

16) Типтік қателер

DLQ → метадеректерінің болмауы себептерін кластерлеу және қауіпсіз қайта өңдеу мүмкін емес.
Лимитсіз жаппай редрайв → продакшеннің қайта тозуы.
Демпотенттік/дедупа → дубль және жанама әсерлер жоқ.
PII-ді орталық DLQ-ға тазартусыз араластыру.
Хабарламалар эволюциясы кезінде схемалар/келісімшарттардың болмауы → «тосын сый».
Тенанттар/кілттер бойынша партияланбаған жалғыз ортақ DLQ.
non-retryable қателер үшін ерте DLQ орнына шексіз ретрайлер.

17) Жылдам рецепттер

Әдеттегі бизнес ағымы: 3-4 әрекеттер, экспоненциалды backoff джиттермен, қателерді ерте жіктеу, толық метадеректермен DLQ.
Сыни оқиғалар (төлем): қатаң теңсіздік, қысқа таймауттар, минималды әрекеттер, жылдам DLQ және қолмен талдау.
Фикстен кейін жаппай редрайв: small batches (100-500), rate-limit, жеке воркер пулы, жылдамдықты арттыру алдында> 95% жетістік мониторингі.
Мульти-тенант: редрайвқа арналған пер-тенанттық лимиттер, DLQ топ-клиент-генераторлары бойынша есеп.

Қорытынды

DLQ - бұл «қоқыс себеті» емес, сенімділіктің бақыланатын контуры. Түсудің нақты ережелері, бай метадеректер, идемпотенттілік және дедупликация, қауіпсіз дозаланған редрайв, схемалар тәртібі және бақылаушылық улы хабарламаларды SLO үшін қауіп-қатерден басқарылатын инженерлік процеске айналдырады - түсінікті плейбуктер, болжамды шығындар және пайдаланушыларға ең аз әсер ету.