Hodisa arxitekturasi

Hodisa arxitekturasi (EDA)

1) Hodisa nima va nega EDA

• xizmatlarning zaif bog’liqligi,
• iste’molchilarni mustaqil ravishda,
• proyeksiyalarni replay/qayta qurish,
• shaffof audit.

EDA sinxron APIlarni bekor qilmaydi - ular asinxron qatlamga kross-servis qaramligini olib, ularni to’ldiradi.

2) Voqealar turlari

Domen: muhim biznes faktlari (OrderPlaced, BonusGranted).
Integratsiyalashgan: tashqi tizimlar uchun «rasmlar «/oʻzgarishlar (UserUpdated, WalletBalanceChanged).
Texnik: hayot sikli va telemetriya (Heartbeat, PipelineFailed).
Buyruqlar (hodisa emas, balki yonma-yon): «Xni qil» (CapturePayment).

Tavsiya: domen voqealari - birlamchi; integratsiyalashuv aniq iste’molchilar uchun proyeksiyalar bilan shakllantiriladi.

3) Voqealar kontraktlari va sxemalari

Схема: Avro/Protobuf/JSON Schema + Schema Registry; muvofiqlik strategiyasi: «BACKWARD» iste’molchilar evolyutsiyasi uchun, «FULL» tanqidiy mavzularda.
CloudEvents (id, source, type, time, subject, datacontenttype) - bir xil sarlavhalar.
Majburiy meta maʼlumotlar:’event _ id’(ULID/UUID),’occurred _ at’,’producer’,’schema _ version’,’correlation _ id ’/’ causation _ id’,’idempotency _ key’.
Versionlash: add-only maydonlari, nomini oʻzgartirish/semantik buzishni taqiqlash; yangi turlari - yangi mavzular/turlar.

json
{
"type":"record","name":"PaymentCaptured","namespace":"events.v1",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"payment_id","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":"string"},
{"name":"player_id","type":"string"}
]
}

4) Yetkazib berish, tartib va kelishuv

At-least-once defolt sifatida → ishlov beruvchilarning idempotentligi kerak.
Tartib: partiya (Kafka) yoki navbat (RabbitMQ) ichida kafolatlanadi, lekin retralarda buzilishi mumkin; hodisa kaliti tartib domen granulasini aks ettirishi kerak (masalan,’player _ id’).
Muvofiqlik: pul/kreditlar uchun - faqat jurnallar/saglar/kompensatsiyalar orqali; LWW dan qoching.

O’qish modeli: proyeksiyalar va keshlar eventual bo’lishi mumkin - «yangilanish davom etmoqda»... ni ko’rsating va qat’iy yo’llar uchun RNOT strategiyalaridan foydalaning.

5) Outbox/Inbox и CDC

Outbox: xizmat o’zining ma’lumotlar bazasiga haqiqatni yozadi va outbox jadvaliga bitta tranzaksiyada → vorker shinaga joylashtiradi.
Inbox: isteʼmolchi’event _ id’ni dedup uchun qayta ishlash natijasi bilan saqlab qoladi.
CDC (Change Data Capture): ilovani oʻzgartirmasdan integratsiya qilish uchun DB (binlog/WAL) dan shinaga oʻzgarishlar oqimi.
Idempotency:’idempotency _ key ’/’ event _ id’boʻyicha ishlov berish.

6) CQRS и Event Sourcing

CQRS: write-model va read-proyeksiyalarni baham ko’ring; proyeksiyalar voqealardan tuziladi va orqada qolishi mumkin.
Event Sourcing: agregat holati = uning voqealari. Ijobiy tomonlari: to’liq audit/replay; minuslar: migratsiya/sxema/snapshot murakkabligi.
Amaliyot: ES - hamma joyda emas, tarix va kompensatsiya muhim bo’lgan joylarda; CQRS - deyarli har doim EDAda.

7) Dostonlar: orkestr va xoreografiya

Orkestr: muvofiqlashtiruvchi buyruqlar yuboradi va javob-hodisalarni kutadi; murakkab jarayonlar uchun qulay (KYC → Deposit → Bonus).
Xoreografiya: xizmatlar bir-birining voqealariga munosabat bildiradi; oson, lekin kuzatish qiyinroq.
Har doim kompensatsiya va muddatlarni belgilang.

8) Topologiyalarni loyihalash (Kafka/RabbitMQ)

Kafka

Domen hodisasi:’payments. captured. v1`, `players. verified. v1`.
Partiyalash kaliti:’player _ id ’/’ wallet _ id’- tartib muhim boʻlgan joyda.
`replication. factor=3`, `min. insync. replicas = 2’, prodyuser’acks = all’.
Retention: vaqt boʻyicha (masalan, 7-90 kun) va/yoki compaction (kalit boʻyicha oxirgi holat).
Backoff bilan retry va DLQ uchun topiklar.

RabbitMQ

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
Keng fan-out uchun -’topic’+ bir necha navbat; RPC/jamoalar uchun - alohida navbatlar.
HA uchun Quorum Queues; Retraylar uchun TTL + dead-letter exchange.

9) Kuzatish va SLO EDA

• End-to-end latency (occurred_at → qayta ishlangan): p50/p95/p99.
• Lag/age: iste’molchilarning orqada qolishi (Kafka consumer lag, Rabbit backlog age).
• Nashr/qayta ishlash usuli.
• DLQ-rate va takrorlash ulushi.
• Biznes-operatsiyalarning muvaffaqiyati (masalan, «depozit 5s ≤ tasdiqlangan»).

• Voqealarni’trace _ id ’/’ correlation _ id’(OTel) orqali bogʻlash.
• Metrik trassadan (exemplars) nusxalar.
• «Producer → Broker → Consumer» dashbordlari burn-rate alertlari bilan.

10) Repley, retenshn va backfill

Proyeksiya/xatolarni tuzatish uchun replay: yangi proyeksiya/neyspeysga haydang, so’ngra o’qishni o’zgartiring.
Retenshn: yuridik/biznes talablari (GDPR/PCI); sezgir maydonlar - shifrlang va/yoki tokenlang.
Backfill: bir martalik mavzular/navbatlar, RPSning aniq chegaralari.

11) Xavfsizlik va komplayens

TLS in-transit, mTLS ichki mijozlar uchun.
Avtorizatsiya: per-topic/per-exchange ACL; multitenancy namespace/vhost orqali.
PII: hodisadagi maydonlarni minimallashtirish; envelope meta ma’lumotlar alohida, foydali yuklamalarni zarur bo’lganda shifrlash.
Voqealarga kirish auditi, «hamma narsaga qodir» kalitlarni taqiqlash.
Retenshn siyosati va oʻchirish huquqi (GDPR): maʼlumot bogʻlamalarini yoki tombstone hodisalarini va oʻchirishni proyeksiyalarda saqlang.

12) EDAda test sinovi

Contract tests: Iste’molchilar o’zlarining sxemalarini (consumer-driven) tasdiqlaydilar.
Replay-testlar: yangi ishlov beruvchi/sxema versiyasi orqali tarixiy tanlash.
Chaos stsenariylari: brokerning kechikishi/yo’qolishi, uzellarning yiqilishi, iste’molchining orqada qolishi → SLO doirasida qoladi.
CIdagi smoke: vaqtinchalik mavzularda qisqa end-to-end paypline.

13) «CRUD-integratsiyalar → EDA» migratsiyasi

1. Domen faktlarini aniqlang.
2. Outboxni boshlangʻich xizmatlarga kiriting.
3. Minimal domen hodisalarini nashr eting va 1-2 ta proyeksiyani ulang.
4. Sinxron integratsiyalarni obunalar bilan almashtirish orqali asta-sekin oʻchiring.
5. Schema registry va moslashuv siyosatini kiriting.
6. Voqealarni add-only bilan kengaytiring; parchalar - faqat yangi turlar orqali.

14) Anti-patternlar

Hodisalar = «DTO API» (juda yog’li, ichki modelga bog’liq) - iste’molchilarni buzadi.
Schema Registry va muvofiqligi yo’qligi - «mo’rt» integratsiya.
Koddan nashr etish va DBga yozish atom emas (outbox yoʻq) - voqealarni yoʻqotasiz.
«Exactly-once hamma joyda» - foydasiz yuqori narx; yaxshiroq at-least-once + idempotentlik.
Partiyalashning bitta «universal» kaliti → qizg’in partiya.
Prod-proyeksiyaga to’g’ridan-to’g’ri gapirish - onlayn SLOlarni buzadi.

15) Joriy etish chek-varaqasi (0-45 kun)

0-10 kun

Domen hodisalari va ularning kalitlarini (tartib granulalari) aniqlash.
Shema registrini kengaytirish va muvofiqlik strategiyasini tasdiqlash.
1-2 servisga outbox/inbox qoʻshish; minimal CloudEvents-envelope.

11-25 kun

Retry/DLQ, backoff, ishlov beruvchilarning idempotentligini kiritish.
Dashbordlar: lag/age/end-to-end; burn-rate alerta.
Hodisa hujjatlari (katalog), owner’lar va sxemalarni tahrirlash jarayonlari.

26-45 kun

Birinchi proyeksiyani replay/qayta qurish; runbook replay va backfill.
Xavfsizlik siyosati (TLS, ACL, PII), retenshn, GDPR-protseduralar.
Broker va iste’molchilar uchun muntazam chaos-va game-days.

16) Etuklik metrikasi

Domen hodisalarining 100% sxemalar bilan tavsiflangan va roʻyxatdan oʻtgan.
Outbox/inbox Tier-0/1 barcha ishlab chiqaruvchilari/konsumerlarini qamrab oladi.
SLO: p95 end-to-end latency va consumer lag maqsadlar doirasida ≥ 99%.
Replay/Backfill to’xtovsiz amalga oshirilishi mumkin; tekshirilgan runbook’lar mavjud.
Versionlash: yangi maydonlar - sinmasdan; eski iste’molchilar tushmaydi.
Xavfsizlik: TLS + mTLS, ACL per topic, kirish jurnallari, PII/retenshn siyosati.

17) Mini-snippetlar

properties acks=all enable.idempotence=true max.in.flight.requests.per.connection=1 compression.type=zstd linger.ms=5

python if inbox.contains(event_id): return # дедуп process(event)            # побочные эффекты детерминированы inbox.commit(event_id)        # atomically with side-effect commit_offset()

• `queue: tasks` → on nack → DLX `tasks. retry. 1m’(TTL = 60s) → qaytish’tasks’; keyingi o’rinlarda’5m/15m’deb ataladi.

18) Xulosa

EDA integratsiyani aniq shartnomalar va boshqariladigan muvofiqlikka ega biznes-faktlar oqimiga aylantiradi. Poydevor qo’ying: sxemalar + reyestr, outbox/inbox, tartib kalitlari, idempotent ishlov beruvchilar, SLO va kuzatish qobiliyati, xavfsiz retenshn va replay. Shunda voqealar sizning «haqiqat manbangizga» aylanadi.