Outbox table — biznes ma’lumotini o‘zgartirish va tashqi event yuborish orasidagi dual-write muammosini kamaytirish uchun shu database tranzaksiyasida event yozuvi saqlanadigan jadvaldir. Ilova orderni commit qilib, brokerga alohida yuborsa, ikki amaldan biri muvaffaqiyatsiz bo‘lishi mumkin. Outbox biznes qatori va nashr qilinadigan recordni atomik commit qiladi.
Yozish oqimi
Business transaction ichida domen qatori yangilanadi va outboxga unique event ID, aggregate ID, type, payload, timestamp hamda schema version yoziladi. Tranzaksiya rollback bo‘lsa ikkala o‘zgarish ham yo‘q. Alohida relay committed outbox recordlarini o‘qib, message brokerga nashr qiladi.
Relay polling bilan published_at bo‘sh qatorlarni olishi yoki CDC orqali transaction logdan recordlarni kuzatishi mumkin. Polling sodda, lekin interval latency va database yukini belgilaydi. Bir nechta worker FOR UPDATE SKIP LOCKED singari mexanizm bilan qatorlarni bo‘lishi mumkin. CDC kamroq polling qiladi, ammo connector infratuzilmasini talab etadi.
Yetkazish semantikasi
Relay brokerga yuborib, outboxni “published” belgilashdan oldin qulasa, event yana yuboriladi. Avval belgilab, keyin yuborsa event yo‘qolishi mumkin. Shu sababli at-least-once va consumer idempotency odatiy yechimdir. Broker deduplication yoki transactional producer yordam beradi, lekin end-to-end chegara aniq tekshiriladi.
Event ID consumer inbox jadvalida unique saqlanishi mumkin. Aggregate bo‘yicha sequence tartibni tekshiradi. Turli aggregate eventlari global qat’iy tartibga muhtoj bo‘lmasa parallel nashr qilinadi. Bitta aggregate partition key sifatida ishlatilsa broker ichida ketma-ketlik saqlanadi.
Jadval boshqaruvi
Outbox tez o‘sadi. Published recordlar retention bo‘yicha partition drop yoki batch delete bilan tozalanadi. Katta delete transaction log va lockni ortiqcha band qilmasligi kerak. Payloadda kerakli biznes faktlari bo‘ladi; butun row yoki maxfiy fieldlarni ko‘r-ko‘rona nusxalash data leakage va schema coupling yaratadi.
Relay lag, eng eski unpublished record, nashr xatolari va retry soni kuzatiladi. Poison event serialization yoki broker cheklovi sabab doim xato qilsa, butun oqimni to‘smasdan quarantine qilinadi, ammo biznes hodisa jim tashlanmaydi. Alert egasi uni tuzatib, qayta nashr qiladi.
Outbox distributed transactionni barcha holatda almashtirmaydi. U bitta local database transactionda yaratilgan faktni ishonchli tarqatishga mos. Ikki mustaqil bazani bir payt atomik o‘zgartirish uchun saga, idempotent command yoki boshqa koordinatsiya kerak.
Amaliy nazorat
Relay brokerga yuborib published belgisidan oldin qulasa event qayta ketadi, shu sababli consumer idempotency end-to-end talabdir. Outbox table 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.
Jadval cheksiz o‘smasligi uchun tasdiqlangan yozuvlar retention siyosati asosida bo‘lib-bo‘lib o‘chiriladi yoki arxivlanadi. Tozalash relaying bilan poygalashmasligi, indekslar esa unpublished yozuvlarni topish so‘roviga mos bo‘lishi kerak. Katta backlog paytida throttling asosiy tranzaksiyalarni himoya qiladi.
Bog‘liq tushunchalar
Transactional outbox, Dual write, CDC, Message broker, Idempotency, Inbox pattern, Saga pattern