Bosh sahifa Wiki Event-driven architecture

Event-driven architecture

Event-driven architecture — tizim komponentlari holatdagi muhim o‘zgarishlarni event sifatida e’lon qiladigan va boshqa komponentlar ularga asinxron javob beradigan arxitektura usuli. OrderPlaced, PaymentConfirmed yoki FileUploaded kabi event o‘tgan hodisani bildiradi. Producer iste’molchini bevosita chaqirmasligi sabab komponentlar vaqt va joylashuv bo‘yicha bo‘shroq bog‘lanadi.

Event, command va message

Message — transport orqali uzatiladigan umumiy birlik. Command ma’lum qabul qiluvchidan amal bajarishni so‘raydi, masalan ReserveStock. Event esa allaqachon sodir bo‘lgan faktni bildiradi va unga nol, bitta yoki ko‘p consumer javob berishi mumkin. Event nomining o‘tgan zamonda bo‘lishi uning semantikasini aniqroq qiladi.

Notification event faqat identifikator berib, consumer’ni qo‘shimcha API chaqirishga majbur qiladi. Event-carried state transfer esa kerakli snapshotni xabarning o‘zida uzatadi. Birinchisi payloadni kichraytiradi, ikkinchisi runtime coupling va qo‘shimcha so‘rovni kamaytiradi; maxfiylik hamda schema hajmi muvozanatlanadi.

Broker va oqim

Producer eventni brokerga yozadi. Broker topic, queue yoki stream orqali consumerlarga yetkazadi. Queue’da xabar odatda consumer guruhidagi bitta workerga beriladi; pub/sub’da bir necha subscription mustaqil nusxa oladi. Log-based stream eventlarni retention muddati davomida saqlab, consumerga offset bo‘yicha qayta o‘qish imkonini beradi.

Element Vazifa
Producer Hodisani aniqlab event yaratadi
Broker Saqlaydi, tartiblaydi va yetkazadi
Consumer Eventga javoban amal bajaradi
Schema registry Payload formatini boshqaradi
Dead-letter queue Qayta ishlanmagan xabarni ajratadi

Yetkazib berish semantikasi

At-most-once xabarni qayta yubormaydi, shu sabab yo‘qolishi mumkin. At-least-once retry orqali yo‘qolishni kamaytiradi, lekin duplicate beradi. “Exactly once” odatda aniq chegaradagi broker va processing transaction’iga tegishli; tashqi email yoki payment API uchun avtomatik kafolat emas.

Consumer idempotency key saqlashi, upsert ishlatishi yoki biznes amalini holat mashinasi bilan himoyalashi mumkin. Xabarni processed deb belgilash va biznes yozuvini yangilash bitta atomic transaction’da bo‘lmasa, crash oralig‘ida yo‘qolish yoki takror yuz beradi.

Tartib va vaqt

Global ordering qimmat va ko‘pincha zarur emas. Broker partition ichida tartibni saqlashi, bir aggregate identifikatorini bir partitionga yo‘naltirishi mumkin. Turli aggregate eventlari parallel qayta ishlanadi. Consumer eski version event kech kelishini ham hisobga oladi.

Event time hodisa manbada sodir bo‘lgan vaqt, processing time consumer uni ko‘rgan vaqt. Stream processing’da kechikkan event, watermark va window siyosati natijaga ta’sir qiladi. Mashinalar soati sinxron bo‘lmasa timestamp mutlaq tartibni isbotlamaydi.

Schema evolyutsiyasi

Event tarixiy yozuv bo‘lishi mumkin; bugungi consumer eski payloadni ham o‘qishi kerak. Field qo‘shish odatda backward-compatible, majburiy fieldni olib tashlash yoki ma’nosini o‘zgartirish esa xavfli. Schema version, default qiymat va compatibility tekshiruvi deploymentdan oldin bajariladi.

Eventda ichki database modelini to‘liq chiqarish coupling va maxfiy ma’lumot tarqalishini oshiradi. Stable public contract faqat consumerlar uchun kerakli ma’lumotni beradi. Sensitive field retention va access policy bilan boshqariladi.

Ishonchlilik and kuzatuv

Database transaction tugab, event publish bo‘lmay qolishi dual-write muammosidir. Transactional outbox biznes yozuvi va outbox satrini bir transaction’da saqlaydi; alohida publisher keyin brokerga uzatadi. Consumer lag, queue depth, oldest-message age, retry va dead-letter soni monitoring qilinadi.

Asinxron zanjir oddiy request stack trace’ida ko‘rinmaydi. Correlation ID, causation ID va trace context event headerida uzatiladi. Replay yangi consumer qurish yoki xatodan tiklanishga yordam beradi, ammo tashqi side effectlar replay paytida takrorlanmasligi kerak.

Bog‘liq tushunchalar

Message broker, Event sourcing, Publish–subscribe, Stream processing, Idempotency, Transactional outbox, Schema evolution