Əməliyyat mesajlaşması

Əməliyyat mesajlaşması - lokal vəziyyət dəyişiklikləri (BD/cache) və broker/şində mesajlar arasında uyğunluğu təmin edən bir sıra memarlıq üsullarıdır. Məqsəd: nasazlıqlar, retrajlar, miqyaslandırma və multitenantlıq zamanı «vəziyyət qeydə alınıb, mesaj itirilməyib və təkrarlanmır».

1) Çatdırılma semantikası

At-most-once: sürətli və ucuz, itki mümkündür, dubl yoxdur.
At-least-once: mesajları itirmir, mümkün dubllar → idempotentlik tələb olunur.
(Effektiv) Exactly-once: Heç bir itki və görünən iş effektləri üçün heç bir ikiqat, texnika kombinasiyası (outbox/inbox, prodüser/məsləhətçi əməliyyatları, dedup) ilə əldə edilir.

2) Niyə «iki imza» təhlükəlidir

Sadəlövh məntiq «əvvəlcə DB-yə yazaq, sonra şinə göndərək» (və ya əksinə) addımlar arasında düşdükdə cırılır: məlumatlar qeydə alınır və hadisə itirilir; və ya hadisə getdi və məlumat yoxdur. Əməliyyat mesajlaşması bu boşluğu aradan qaldırır.

3) Əsas nümunələr

3. 1 Outbox (istehsalçı)

Bir lokal əməliyyatda biznes dəyişikliyi və sətri «outbox» cədvəlinə yazırıq; ayrı publicher outbox oxuyur və retras və backoff ilə broker dərc edir. Itkilər istisna edilir; dubli istehlakçıların idempotentliyi ilə söndürülür.

3. 2 Inbox/Idempotent Consumer (istehlakçı)

Effektin yerinə yetirilməsindən əvvəl konsumer əsas açar kimi 'INSERT' in 'inbox (consumer, event_id) edir. Açar münaqişəsi = hadisə artıq işlənib hazırlanıb → buraxılır. Beləliklə, «effektiv exactly-once» əldə edilir.

3. 3 Ofset əməliyyatı ilə Read-Process-Write

Log-yönümlü şinlər üçün şablon: konsumer batch oxuyur, eyni əməliyyatda iş dəyişikliyini və «keçmiş ofseti» qeyd edir. Kommitdən sonra broker mesajları istehlak hesab edir. Bu aradan qaldırır «oxundu → düşdü → təkrarlandı» effektində dubl olmadan.

3. Servislərarası effektlər üçün 4 TSS/Saga

Razılaşdırılmış multişaq prosesi lazım olduqda, TCC və ya dastan istifadə edin; mesajlar - komandaların/hadisələrin daşınması, tranzaksiya - addım və kompensasiya səviyyəsində.

4) İdempotent prodüserlər və konsumerlər

Prodüser: sabit 'message _ id '/' idempotency _ key', eyni açarla təkrar göndərmə abunəçilər üçün yeni effektlər yaratmır; açar ardıcıllığını (sequence) saxlayın.
Konsumer: 'inbox' + biznes idempotentliyi (upsert/merge, son versiya/reviziya yoxlaması).

5) Sifariş və səbəb

Biznes açarı ilə partiyalaşdırın (məsələn, 'aggregate _ id', 'tenant _ id') ki, bir obyektin hadisələri qaydasında olsun.
Partiya daxilində ardıcıl nömrələri/vaxt işarələrini saxlayın; DLQ-dən redrave edərkən «açar və ardıcıl» edin.
Qlobal sifariş kritik deyilsə, lokal açar sifarişini təmin edin və domen invariantlarını düzəldin.

6) Offset və fiksasiya effektləri

Variant A: «DB Offset»

«Son işlənmiş ofset (partition, offset)» domen məlumatlarını dəyişdirdiyiniz eyni əməliyyata yazın. Restart zamanı təkrar effektdən qaçaraq növbəti ofsetdən davam edin.

Variant B: «Broker əməliyyatı»

Bəzi brokerlər bir prodüser/müştəri əməliyyatı çərçivəsində mesajların və ofsetlərin atom yazısını dəstəkləyirlər. Mövcud olduqda istifadə edin, lakin həmişə istehlakçıda idempotentliyi tamamlayın.

7) Retrai, backoff, DLQ

eksponensial backoff və jitter ilə yalnız retraibl səhvləri (zaman, 5xx) təkrarlayın.
Non-retraibl (schema/validation) - dərhal DLQ-də meta-məlumatlarla (tenant, key, offset, səbəb).
DLQ-dən Redrive dozası (batch, rate limit), yenidən başlamazdan əvvəl sxemi yoxlayın, açar qaydasına riayət edin.

8) Multi-tenantlıq və regionlar

'tenant _ id', 'plan', 'region' -u meta məlumatlara və partizan açarlarına daxil edin.
Per-tenant fairness: «səs-küylü» müştərinin digərlərindən büdcə çıxarmaması üçün nəşr/emalı məhdudlaşdırın.
Residency: domen məlumatları ilə eyni bölgədə mesajları və outbox saxlayın; regionlararası replikasiyalar - asinxron aqreqatlar.

9) Müşahidə və audit

Treysinq: 'event _ id '/' aggregate _ id '/' saga _ id' korrelyasiyası, yuxular «read → process → write/commit».
Metriklər: nəşr/emal lag (p95/p99), müvəffəqiyyət payı, DLQ-rate, redrayv müvəffəqiyyəti, «dublikatlar yatırıldı».
Logi: qısa uğur; səhvlər ətraflı (səbəb, cəhd, açar, ofset).
Audit: kim redrayvil/konki, hansı batch və hansı nəticə ilə.

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

Payload-da PII-ni minimuma endirin; DLQ/log-a köçürüldükdə maskalayın.
Xarici təkərlər üçün mesajları imzalayın/şifrələyin; xidmətlər arasında mTLS istifadə edin.
Saxlama müddətini və «unudulma hüququnu» idarə edin per tenant/region.

11) Standart inteqrasiya sxemləri

1. Xidmət mənbəyi (write-side)

Yerli əməliyyat: domen qeydiyyatı + outbox.
Reklam: batchi, 'SKIP LOCKED', backoff, limitlər per tenant.
lag 'now − occurred_at' monitorinqi.

2. Xidmət-istehlakçı (read-side)

Batch oxumaq → cəhd 'INSERT inbox (consumer, event_id)' → müvəffəqiyyətlə effekt yerinə yetirmək.
Eyni əməliyyatda «keçmiş ofset» (variant A) və ya broker əməliyyatına (variant B) güvənirik.
Səhv: retraj və ya DLQ siyasət.

3. Proyeksiya/materiallaşdırılmış görünüş

Yalnız idempotent yeniləmələr (upsert), kompakt dedup açarları, dövri yoxlama məbləğləri.

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

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Satış öncəsi yoxlama siyahısı

• «İki imza» aradan qaldırıldı: prodüserdə outbox və ya konsumerdə bir əməliyyatda ofset və effektin fiksasiyası.
• İdempotent müştəri: 'inbox '/dedup jurnalı, əməliyyatların biznes idempotantlığı.
• Biznes açarı ilə partizanlaşdırma, yerli qaydaya riayət olunur.
• Backoff + Jitter ilə retrailer, səhvlərin təsnifatı, zəngin metadata ilə DLQ.
• Redrave dozalı, təhlükəsiz; playbook var.
• Multi-tenant limitlər və prioritetlər; tags 'tenant _ id/plan/region'.
• Telemetriya: lag, müvəffəqiyyət payı, «dublikatlar sıxışdırılır», p95/p99 üçün alertlər.
• PII/retenshn/şifrələmə siyasətlərinə əməl olunur.
• Testlər: addımlar arasında düşmə, dublikatlar, açar qaydası, kütləvi redrave.

14) Tipik səhvlər

Outbox/offset əməliyyatı olmadan ayrı addımlarla şinə göndərin və DB-yə yazın.
İdempotentlik olmadan konsumer → yan təsirləri təkrarlayır.
Qlobal nizam «nə olursa olsun» - bahalı və nadir hallarda əsaslandırılır; açar üçün kifayət qədər sifariş.
Limitsiz kütləvi redrayv → ikincili hadisə.
Trace-in olmaması/lag-metrik → «gizli deqradasiya».
DLQ/log PII qarışdırılması.

15) Sürətli reseptlər

SaaS-hadisələr: Outbox + idempotent consumer (inbox), partizan 'tenant _ id: aggregate _ id'.
ETL/proyeksiyaları: Bir əməliyyatda ofset fiksasiyası ilə Read-process-write, 500-1000 batch, upsert.
Yüksək yük: reklam, 'SKIP LOCKED', WFQ per tenant, laq nəzarəti.
Ciddi uyğunluq zonası: regional outbox, payload şifrələmə, retenshn və redrive audit.

Nəticə

Əməliyyat mesajlaşması məlumat və mesajların birləşdirilməsi intizamıdır. Outbox/inbox, idempotentlik, ofset fiksasiyası və DLQ ilə idarə olunan retrajları birləşdirərək, qlobal kilidlər olmadan praktik exactly-once davranışı əldə edirsiniz və hətta uğursuzluqlar, zirvələr və mürəkkəb çox tenant əməliyyat zamanı SLO saxlayırsınız.