Inbox pattern — message consumer takror yetkazilgan xabarni qayta ishlamasligi uchun qabul qilingan event yoki command identifikatorini local saqlash usulidir. Broker at-least-once ishlaganda producer yoki tarmoq xatosi bir recordni bir necha marta olib kelishi mumkin. Inbox consumerning biznes o‘zgarishi bilan deduplication yozuvini bir tranzaksiyada birlashtiradi.
Qabul qilish tartibi
Consumer xabardan barqaror unique ID oladi. Database transaction ichida inbox jadvaliga shu ID’ni insert qiladi. Unique constraint buzilsa, xabar avval qayta ishlangan deb olinadi va biznes amal takrorlanmaydi. Insert muvaffaqiyatli bo‘lsa, domen holati yangilanib, transaction commit qilinadi; shundan keyin broker acknowledgement oladi.
Agar process commitdan keyin, ackdan oldin qulasa, broker xabarni qayta beradi, ammo inbox unique constraint uni to‘xtatadi. Ack commitdan oldin yuborilsa va transaction rollback bo‘lsa xabar yo‘qoladi. Shu sababli tashqi protokol va local commit tartibi aniq boshqariladi.
Identifikator va scope
Event ID producer tomonidan har mantiqiy hodisa uchun bir marta yaratiladi. Har retry’da yangi ID berilsa deduplication ishlamaydi. Bir nechta producer bir xil formatdan foydalansa, ID globally unique yoki (producer, id) composite key bo‘ladi. Tenant ID ham scope’ga kirishi mumkin.
Inbox “bir xil mazmun”ni emas, bir xil identifikatorni taniydi. Ikki mustaqil, lekin teng payload alohida event bo‘lishi mumkin. Payload hash yordamchi integrity yoki noto‘g‘ri ID reuse’ni aniqlaydi, ammo maxfiy mazmunni unnecessary saqlamaslik kerak.
Tartib va holat
Faqat deduplication eventlar tartibini hal qilmaydi. Aggregate sequence oldingi versiyadan bittaga katta bo‘lishini tekshiradi. Kelajakdagi event erta kelsa, vaqtincha kutish, qayta urinish yoki source’dan holatni tiklash siyosati kerak. Eski sequence takror yoki obsolete deb qabul qilinadi.
Uzoq davom etadigan handlerda inboxni darhol “processed” belgilash xavfli. Jadval received, processing, completed, failed holatlarini saqlashi mumkin, lekin lease va recovery murakkablashadi. Imkon qadar local biznes yozuvi bilan qisqa atomik tranzaksiya qo‘llanadi, tashqi yon ta’sir uchun esa outbox yaratiladi.
Retention va monitoring
Inbox cheksiz o‘smasligi uchun retention belgilanadi. Deduplication oynasi broker maksimal redelivery va producer retry muddatidan uzun bo‘lishi kerak. Eski recordni juda erta o‘chirish kechikkan takrorni qayta bajaradi. Partition va indexed timestamp tozalashni yengillashtiradi.
Duplicate soni, unique constraint xatosi, handler latency va failed holatlar metrikaga aylanadi. Keskin duplicate o‘sishi producer retry storm yoki ack muammosini bildiradi. Inbox yozuvi audit uchun minimal metadata saqlaydi; to‘liq shaxsiy payload alohida ehtiyoj bo‘lmasa yozilmaydi.
Amaliy nazorat
Inbox unique event ID va biznes o‘zgarishini bir local tranzaksiyada saqlab, commitdan keyingi redeliveryni xavfsiz takror sifatida taniydi. Inbox pattern bo‘yicha nazorat faqat bitta input filterga tayanmaydi. API erkin sintaksis o‘rniga aniq identifikator va typed parametr qabul qiladi, jarayon esa least privilege bilan ishlaydi. Normal holat bilan birga encoding, duplicate, timeout, parallel so‘rov va qisman nosozlik test qilinadi. Production telemetry xato turi, kechikish va rad etilgan urinishlarni ko‘rsatadi, maxfiy payloadni to‘liq jurnalga yozmaydi. O‘zgarish avval kichik doirada sinovdan o‘tib, regression kuzatilmagach kengaytiriladi. Incident runbook ta’sirlangan obyektlarni aniqlash, credential yoki holatni tiklash va sababni kod darajasida bartaraf etishni belgilaydi.
Bog‘liq tushunchalar
Idempotent consumer, At-least-once delivery, Deduplication, Outbox pattern, Message broker, Sequence number, Acknowledgement