3.12 ایونٹ پر مبنی فن تعمیر اور پیغام رسانی

جائزہ اور محرکات

ایونٹ پر مبنی فن تعمیر (EDA) ایسا اسلوب ہے جس میں اجزا ایک دوسرے کو براہ راست کال کرنے کی بجائے ایونٹس پیدا کر کے اور ان پر ردعمل دے کر رابطہ کرتے ہیں۔ ایونٹ ایک حقیقت ہے: ایسی چیز جو پہلے ہو چکی، جیسے “OrderPlaced” یا “PaymentCaptured”۔ پیدا کرنے والا حقیقت کا اعلان کر کے آگے بڑھ جاتا ہے، اور کوئی بھی تعداد کے صارفین اپنے شیڈول پر ردعمل دیتے ہیں بغیر اس کے کہ پیدا کرنے والا جانے کون سن رہا ہے۔ یہ باب 2.3 کی درخواست اور جواب کی کالز سے مختلف رویہ ہے، جہاں کال کرنے والا مخصوص سروس سے کچھ کرنے کو کہتا ہے اور جواب کا انتظار کرتا ہے۔

بڑے ادارے کے لیے کشش پیمانے پر جوڑ ڈھیلا کرنا ہے۔ جب آپ کے پاس درجنوں ٹیمیں اور سینکڑوں سروسز ہوں تو سب کو براہ راست نقطہ بہ نقطہ کالز سے جوڑنا نازک جال پیدا کرتا ہے جہاں ایک ٹیم کی تبدیلی دوسری کو توڑتی ہے اور کوئی نہیں بتا سکتا کیوں۔ ایونٹس ٹیموں کو ایک دوسرے کے اندرونی حصوں کی بجائے حقائق کی مشترک دھار سے ضم ہونے دیتے ہیں، اور نیا صارف سبسکرائب کر کے شامل ہوتا ہے، پیدا کرنے والے کے کوڈ کی ایک لائن بدلے بغیر۔ یہی خاصیت، خام تھرو پٹ سے زیادہ، وجہ ہے کہ ایونٹ پر مبنی طریقے انٹرپرائز میں الجھے انضمام کی جگہ لیتے پھیلتے رہتے ہیں اور حکومتوں میں ایسی ایجنسیوں کو جوڑتے ہیں جو ہر ایک اپنے نظاموں کی مالک ہے۔

سرکاری شعبے کو دوسرا فائدہ ملتا ہے جس کی قدر کم لگانا آسان ہے: جو ہوا اس کا پائیدار، ترتیب وار ریکارڈ آڈٹ اور شفافیت کا اثاثہ ہے۔ جب شہری پوچھے کہ فائدے کا فیصلہ ایسے کیوں نکلا تو اس تک لے جانے والے ایونٹس کا ناقابل تبدیل لاگ براہ راست جواب دیتا ہے۔ مگر ایونٹ پر مبنی ڈیزائن مفت نہیں اور ہمیشہ درست نہیں: غیر ہم وقت بہاؤ کا سراغ لگانا مشکل ہے، ان پر استدلال کرنا مشکل ہے، اور ضرورت سے زیادہ لاگو کرنا آسان۔ یہ باب اس بارے میں رائے رکھتا ہے کہ کب جوڑ ڈھیلا کرنا اور پیمانہ اضافی پیچیدگی کی ادائیگی کرتے ہیں، اور کب سادہ ہم وقت کال آپ کی بہتر خدمت کرتی۔ یہ باب 3.3 کی تقسیم شدہ نظاموں کی حقیقتوں پر بنتا ہے، اس لیے اگر آپ نے نہیں پڑھا تو پہلے وہ پڑھیں۔

بنیادی اصول

ایونٹس حقائق ہیں، ہدایات نہیں۔ ایونٹ بتاتا ہے کہ کیا ہوا؛ کمانڈ کسی کام کی درخواست کرتی ہے۔ انہیں الگ رکھیں، اور ایونٹس کے نام ماضی کے صیغے میں رکھیں۔
جوڑ ڈھیلا کرنا ہی مقصد ہے۔ پیدا کرنے والوں کو نہیں جاننا چاہیے یا پروا کرنی چاہیے کہ ان کے ایونٹس کون استعمال کرتا ہے۔ اگر کرتے ہیں تو آپ کے پاس پیغام رسانی کا لباس پہنے جوڑ ہے۔
کم از کم ایک بار ترسیل کے لیے ڈیزائن کریں۔ بالکل ایک بار ترسیل افسانہ ہے۔ ہر صارف کو یکساں اثر والا بنائیں تاکہ نقلیں بے ضرر ہوں۔
ترتیب وہ ضمانت ہے جس کی آپ قیمت دیتے ہیں۔ آپ کو ترتیب پارٹیشن کے اندر ملتی ہے، ٹاپک کے پار نہیں۔ پارٹیشن کی کلیدیں جان بوجھ کر چنیں۔
اسکیما معاہدہ ہے۔ ایونٹ کی شکل عوامی انٹرفیس ہے؛ اسے اتنی احتیاط سے ارتقا دیں جتنی شائع شدہ API کو دیں گے۔
غیر ہم وقت کا مطلب ناقابل مشاہدہ نہیں۔ اگر آپ پیغام کو شروع سے آخر تک فالو نہیں کر سکتے تو آپ نظام کو چلا نہیں سکتے۔
پیچیدگی کمائی جانی چاہیے۔ ایونٹ سورسنگ، CQRS، اور ساگاز طاقتور اور مہنگے ہیں؛ ان تک تب پہنچیں جب مسئلہ تقاضا کرے، بذریعہ ڈیفالٹ نہیں۔

سفارشات

کچھ بنانے سے پہلے ایونٹس، کمانڈز، اور پیغامات میں فرق کریں

یہ تین الفاظ ایک دوسرے کی جگہ استعمال ہوتے ہیں، اور الجھن حقیقی ڈیزائن کی غلطیاں پیدا کرتی ہے۔ کمانڈ کچھ کرنے کی درخواست ہے (“CapturePayment”)، ایک ہینڈلر کو ہدایت شدہ، اور رد ہو سکتی ہے۔ ایونٹ اطلاع ہے کہ کچھ پہلے ہو چکا (“PaymentCaptured”)، ہر دلچسپی رکھنے والے کو نشر ہوتا ہے، اور رد نہیں ہو سکتا کیونکہ حقیقت پہلے سے سچ ہے۔ پیغام غیر جانبدار لفافہ ہے جو تار پر دونوں میں سے کوئی لے جاتا ہے۔ فرق جوڑ کو شکل دیتا ہے: کمانڈز بھیجنے والے کو مخصوص وصول کنندہ اور نتیجے سے جوڑتی ہیں، جبکہ ایونٹس اس پر کنٹرول چھوڑ دیتے ہیں کہ آگے کیا ہوگا۔ اپنے ایونٹس کے نام ماضی کے صیغے میں رکھیں، اور جب آپ خود کو ایسا “ایونٹ” شائع کرتے پائیں جس کا اصل مطلب “براہ کرم جا کر یہ مخصوص کام کرو” ہے تو آپ نے بھیس بدلی کمانڈ لکھی ہے۔

قطاریں، لاگز، اور publish/subscribe جان بوجھ کر چنیں

تمام پیغام رسانی ایک ہی شکل کی نہیں، اور غلط چننا ابتدائی عام غلطی ہے۔ پیغام کی قطار ہر پیغام ایک صارف کو پہنچاتی ہے اور عموماً پروسیس ہونے پر اسے ہٹا دیتی ہے، جو کام کی تقسیم کو موزوں ہے: بہت سے ورکرز ٹاسک کھینچتے ہوئے، ہر ایک ایک بار مکمل۔ پائیدار ایونٹ لاگ (سٹریم) ایونٹس کو ترتیب میں رکھتا ہے اور بہت سے آزاد صارفین کو اپنی رفتار سے پڑھنے دیتا ہے، کسی بھی نقطے سے تاریخ دوبارہ چلاتے ہوئے، جو ایونٹ کی تقسیم اور آڈٹ کو موزوں ہے۔ Publish/subscribe میں پیدا کرنے والے ٹاپک پر شائع کرتے ہیں اور متعدد سبسکرائبرز ہر ایک اپنی نقل پاتے ہیں۔ عملی اصول: اگر پیغام ایسا ٹاسک ہے جو ایک ورکر کو مکمل کرنا چاہیے تو قطار تک پہنچیں؛ اگر وہ ایسی حقیقت ہے جس کی بہت سے فریقوں کو ابھی یا بعد میں پروا ہو سکتی ہے تو پائیدار لاگ تک پہنچیں، جو بحالی اور نئے صارفین کو شامل کرنے کے لیے دوبارہ چلانا بھی دیتا ہے۔ دیکھیں باب 3.4 کہ یہ انتخاب آپ کے ڈیٹا کے ذخیرے کی حکمت عملی سے کیسے تعامل کرتے ہیں۔

خود مختاری کے لیے کوریوگرافی، کنٹرول کے لیے آرکسٹریشن کو ترجیح دیں

جب کاروباری عمل کئی سروسز پر پھیلا ہو تو آپ اسے دو طریقوں میں سے ایک سے ہم آہنگ کرتے ہیں۔ کوریوگرافی میں ہر سروس ایونٹس پر ردعمل دیتی اور اپنے خارج کرتی ہے، کوئی مرکزی دماغ نہیں: زیادہ سے زیادہ جوڑ ڈھیلا اور ٹیم کی خود مختاری کے لیے اچھا، مگر مجموعی عمل صرف ابھرتے رویے کے طور پر موجود ہے جسے کوئی ایک جگہ بیان نہیں کرتی۔ آرکسٹریشن میں مرکزی کوآرڈینیٹر قدم چلاتا اور پورا بہاؤ جانتا ہے: نگرانی اور تبدیلی میں آسان، اس جزو کی قیمت پر جس پر ہر قدم منحصر ہے۔ اچھا ڈیفالٹ ڈھیلے تعلق والے ردعمل (“جب آرڈر روانہ ہو تو وفاداری کی سروس پوائنٹس دیتی ہے”) کے لیے کوریوگرافی، اور واضح کامیابی کی شرط اور حیثیت رپورٹ کرنے کی ضرورت والی متعین ٹرانزیکشن کے لیے آرکسٹریشن ہے۔ اہم عمل کو دس ایونٹ ہینڈلرز میں بکھرے قبائلی علم کے طور پر نہ رہنے دیں۔

ایونٹ سورسنگ اور CQRS تک صرف تب پہنچیں جب وہ اپنی جگہ کمائیں

ایونٹ سورسنگ حالت کو موجودہ اسنیپ شاٹ کی بجائے جسے آپ اوور رائٹ کریں ایونٹس کی صرف اضافہ ہونے والی ترتیب کے طور پر محفوظ کرتی ہے، اور آپ انہیں دوبارہ چلا کر موجودہ حالت دوبارہ بناتے ہیں۔ فائدہ بہترین آڈٹ کا نشان، کسی بھی ماضی کی حالت دوبارہ تعمیر کرنے کی صلاحیت، اور وقت کے سوالات ہیں؛ لاگت یہ ہے کہ آپ ایونٹ اسکیما ہمیشہ ورژن کرتے ہیں، دوبارہ چلانا اور اسنیپ شاٹ سنبھالتے ہیں، اور ایسا ذہنی ماڈل اٹھاتے ہیں جو زیادہ تر ڈویلپرز نے کبھی استعمال نہیں کیا۔ CQRS (Command Query Responsibility Segregation) لکھنے کے ماڈل کو ایک یا زیادہ پڑھنے کے ماڈلز سے الگ کرتا ہے تاکہ پڑھنا اور لکھنا آزادانہ طور پر پیمائش اور ارتقا کریں؛ یہ ایونٹ سورسنگ کے ساتھ فطری جوڑ بناتا ہے مگر اس کی ضرورت نہیں۔ دونوں حقیقی آڈٹ، تعمیل، یا پیچیدہ سوال کی ضروریات والے ڈومینز کے لیے چمکتے ہیں، اسی لیے ضابطے کے پابند مالیات اور حکومت انہیں تکلیف کے قابل پاتے ہیں۔ سادہ create-read-update-delete سروس کے لیے وہ اتفاقی پیچیدگی ہیں جس پر آپ پچھتائیں گے، اس لیے انہیں اپنے ڈومین کے اس حصے پر لاگو کریں جسے ان کی ضرورت ہے، پورے نظام پر اضطراری طور پر نہیں۔

تقسیم شدہ ٹرانزیکشنز کو دو مرحلہ کمٹ کی بجائے ساگاز سے سنبھالیں

آپ عموماً کئی سروسز اور ڈیٹا بیس کے گرد ایک جوہری ٹرانزیکشن نہیں لپیٹ سکتے۔ تقسیم شدہ دو مرحلہ کمٹ نیٹ ورک پر لاکس تھامتا ہے، دستیابی کاٹتا ہے، اور برے طریقے سے پیمائش کرتا ہے، اس لیے ایونٹ پر مبنی نظام کو شاذ ہی موزوں ہے۔ ساگا پیٹرن اس کی جگہ لیتا ہے: ٹرانزیکشن کو مقامی ٹرانزیکشنز کے سلسلے کے طور پر ماڈل کریں، ہر ایک ایونٹ خارج کرتا ہے جو اگلے کو متحرک کرتا ہے، اور ہر قدم کو تلافی کا عمل دیں جو بعد کا قدم ناکام ہونے پر اسے الٹے۔ اگر “inventory محفوظ کرو” کامیاب ہو مگر “کارڈ چارج کرو” ناکام ہو تو تلافی inventory کو چھوڑ دیتی ہے۔ ساگاز کوریوگراف یا آرکسٹریٹ ہو سکتے ہیں، اور جو کچھ آپ کو مانیٹر کرنا ہو اس کے لیے آرکسٹریشن عموماً جیتتی ہے۔ چونکہ ساگاز حتمی مطابقت کو گلے لگاتے ہیں، نظام ملنے سے پہلے درمیانی حالتوں (“محفوظ مگر ادا نہیں”) سے گزرتا ہے، اس لیے اپنا صارف کا تجربہ اور آڈٹ کا نشان یوں ڈیزائن کریں کہ “زیر عمل” اور “تلافی شدہ” حالتیں ایمانداری سے دکھائیں۔ باب 3.3 یہی زمین تقسیم شدہ نظاموں کے زاویے سے بیان کرتا ہے۔

کم از کم ایک بار ترسیل کے لیے ڈیزائن کریں اور صارفین کو یکساں اثر والا بنائیں

پیغام کے نظام ناکامیوں کے پار بالکل ایک بار واقعی ترسیل نہیں کر سکتے، کیونکہ رسید جو کہتی ہے “میں نے یہ پروسیس کیا” خود کھو سکتی ہے، دوبارہ ترسیل پر مجبور کرتی ہوئی۔ جو آپ حاصل کر سکتے ہیں وہ یکساں پروسیسنگ کے ساتھ کم از کم ایک بار ترسیل ہے، جو بالکل ایک بار اثرات پیدا کرتی ہے۔ یکسانیت کا مطلب ہے ایک ہی ایونٹ کو دو بار پروسیس کرنا وہی نتیجہ چھوڑتا ہے جو ایک بار؛ اس تک ہر ایونٹ پر یکسانیت کی کلید اور جو آپ پہلے سنبھال چکے اس کا ریکارڈ رکھ کر پہنچیں، تاکہ نقل پہچانی اور گرا دی جائے۔ زیادہ سے زیادہ ایک بار ترسیل (آگ لگا کر بھول جاؤ، کوئی دوبارہ ترسیل نہیں) سادہ ہے مگر خاموشی سے پیغامات کھوتی ہے، اس لیے اسے اس ڈیٹا کے لیے رکھیں جسے آپ کھو سکتے ہیں۔ کچھ فروخت کنندگان کے اشتہار شدہ “بالکل ایک بار” لیبل کو شک سے دیکھیں: اس کا مطلب عموماً مخصوص شرائط میں ایک نظام کی حد کے اندر بالکل ایک بار ہے، نہ کہ وہ شروع سے آخر تک کی ضمانت جو جملہ ظاہر کرتا ہے۔

پارٹیشنز سے ترتیب کنٹرول کریں، اور اپنے کنزیومر گروپس جانیں

ترتیب عالمی اور مفت نہیں؛ مقامی اور ادائیگی شدہ ہے۔ سٹریم پارٹیشنز میں تقسیم ہوتی ہے، اور آپ کو ترتیب پارٹیشن کے اندر ملتی ہے، ٹاپک کے پار نہیں۔ ایونٹس پارٹیشن کی کلید سے پارٹیشن کو روٹ ہوتے ہیں، تو اس کلید کا انتخاب ہی کنٹرول کرتا ہے کہ کیا ترتیب میں رہتا ہے: کسٹمر ID سے کلید رکھیں تو ایک کسٹمر کے ایونٹس ایک دوسرے کے مقابل ترتیب میں رہتے ہیں، جبکہ مختلف کسٹمرز متوازی پروسیس ہوتے ہیں۔ کنزیومر گروپس ورکرز کے سیٹ کو ٹاپک کے پارٹیشنز بانٹنے دیتے ہیں، ہر پارٹیشن ایک ورکر کے سنبھالے، جو وہ طریقہ ہے جس سے آپ تھرو پٹ کی پیمائش کرتے ہیں جبکہ فی پارٹیشن ترتیب برقرار رکھتے ہیں؛ یہاں وسعت پذیری درستگی سے ملتی ہے، باب 3.5 سے جڑتے ہوئے۔ ایسی پارٹیشن کی کلید چنیں جو آپ کے حقیقی ترتیب کے تقاضے کی عکاس ہو اور بوجھ یکساں پھیلائے، کیونکہ جو کلید زیادہ ٹریفک ایک پارٹیشن میں بھیجے وہ گرم مقام پیدا کرتی ہے جسے کوئی بھی ورکرز کی تعداد دور نہیں کر سکتی۔

اسکیما کو رجسٹری اور ارتقا کے قواعد کے ساتھ معاہدہ سمجھیں

ایونٹ کی ساخت شائع شدہ انٹرفیس ہے جسے ایسی ٹیمیں استعمال کرتی ہیں جن سے آپ شاید کبھی نہ ملیں، اس لیے اسے بے احتیاطی سے بدلنا انہیں دور سے توڑتا ہے۔ اپنے ایونٹ اسکیما اسکیما رجسٹری میں رکھیں، مشترک کیٹلاگ جو ہر اسکیما محفوظ کرتا ہے اور جب پیدا کرنے والا کسی کو بدلنے کی کوشش کرے تو مطابقت کے قواعد نافذ کرتا ہے۔ واضح پالیسی اپنائیں: پسماندہ مطابقت والی تبدیلیاں (اختیاری فیلڈ جوڑنا) اجازت شدہ ہیں؛ توڑنے والی تبدیلیاں (فیلڈ ہٹانا، قسم بدلنا، نام بدلنا) کو نیا اسکیما ورژن اور منتقلی کا منصوبہ چاہیے۔ یہ پیدا کرنے والوں کو ہر صارف کے پار ہم آہنگ تعیناتی کے بغیر ارتقا کرنے دیتا ہے، جو ٹھیک وہ وجہ ہے جس سے آپ نے ایونٹس چنے۔ باب 2.3 کا انٹرفیس کی ورژننگ کا وہی نظم و ضبط لاگو ہے، کیونکہ ایونٹ کا اسکیما کسی اور نام سے API ہے۔

ترسیل کی ضمانت transactional outbox سے دیں، اور ناکامیاں واضح طور پر سنبھالیں

کلاسیکی بگ: آپ کی سروس اپنے ڈیٹا بیس میں لکھتی ہے اور پھر ایونٹ شائع کرتی ہے، اور دونوں کے بیچ کریش ہو جاتی ہے، اس لیے ڈیٹا بیس بدلا مگر ایونٹ کبھی نہ گیا۔ Transactional outbox اس کی اصلاح ایونٹ کو حالت کی تبدیلی کی اسی ڈیٹا بیس ٹرانزیکشن میں outbox ٹیبل میں لکھ کر کرتا ہے، تاکہ وہ ساتھ کمٹ یا ناکام ہوں؛ الگ relay پھر outbox پڑھتا اور بروکر پر شائع کرتا ہے، اکثر ڈیٹا بیس کے لاگ کی دم پکڑنے کے لیے change data capture استعمال کرتے ہوئے۔ استعمال کی ناکامیوں کے لیے، dead letter queue وہ پیغامات رکھتی ہے جو بار بار ناکام ہوں تاکہ زہریلا پیغام (جو کبھی کامیاب نہیں ہوگا، شاید اس لیے کہ خراب شکل کا ہے) اپنے پیچھے کی قطار کو ہمیشہ کے لیے بلاک نہ کرے۔ بیک پریشر جوڑیں تاکہ تیز پیدا کرنے والا سست صارف کو دبا نہ سکے: اپنی قطاریں محدود کریں، اور جب بھر جائیں تو میموری ختم کرنے کی بجائے بوجھ سست یا گرائیں۔ یہ چار طریقے ڈیمو کو ایسے نظام سے الگ کرتے ہیں جو آپ صبح 3 بجے چلا سکیں۔

غیر ہم وقت بہاؤ کو شروع سے آخر تک قابل مشاہدہ بنائیں

ایونٹ پر مبنی ہونے کی سب سے سخت لاگت یہ ہے کہ ایک کاروباری عمل اب پیدا کرنے والوں، بروکرز، اور صارفین میں بکھر جاتا ہے، کوئی کال اسٹیک انہیں جوڑتا نہیں۔ ہر ایونٹ سے ہم آہنگی کی ID گزاریں تاکہ آپ ایک منطقی بہاؤ کو ہر ہاپ کے پار فالو کر سکیں، وہی نظم و ضبط جو باب 3.3 ہم وقت کالز کے لیے تجویز کرتا ہے۔ کنزیومر لیگ (ہر صارف حقیقی وقت سے کتنا پیچھے پڑھ رہا ہے) کو اولین درجے کی میٹرک کے طور پر ٹریک کریں، کیونکہ بڑھتا لیگ مصیبت کی سب سے پہلی وارننگ ہے، اور dead letter queue کی گہرائی، پروسیسنگ کی لیٹنسی، اور دوبارہ ترسیل کی شرحوں کی نگرانی کریں۔ اس کے بغیر وہ ایونٹ جو خاموشی سے استعمال ہونے میں ناکام ہو غیر مرئی بگ بن جاتا ہے جو دنوں بعد غائب ڈیٹا کے طور پر ظاہر ہوتا ہے۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات / لاگت
ہم وقت درخواست/جواب	استدلال میں سادہ، فوری نتیجہ، آسان سراغ	سخت وقتی جوڑ، زنجیری ناکامیاں، محدود پیمانہ
ایونٹ پر مبنی (لاگ پر pub/sub)	جوڑ ڈھیلا، آزادانہ پیمائش، دوبارہ چلانا، آڈٹ کا نشان	حتمی مطابقت، مشکل سراغ، زیادہ حرکت کرنے والے حصے
پیغام کی قطار (کام کی تقسیم)	بوجھ برابر کرنا، بفرنگ، بیک پریشر دوست	ہر پیغام کے لیے ایک صارف، نشریات کے لیے کم موزوں
ایونٹ سورسنگ + CQRS	مکمل تاریخ، وقت کے سوالات، پڑھنا/لکھنا آزادانہ پیمائش	اسکیما کی ورژننگ ہمیشہ کے لیے، دوبارہ چلانے کی پیچیدگی، سیکھنے کا کھڑا منحنی
ساگا (بمقابلہ دو مرحلہ کمٹ)	قابل پیمائش، دستیاب، تقسیم شدہ لاکس نہیں	حتمی مطابقت، تلافی کی منطق، استدلال مشکل

مرکزی کھنچاؤ جوڑ ڈھیلا کرنے اور قابل فہم ہونے کے درمیان ہے۔ ہر ایونٹ جو آپ جوڑتے ہیں پیدا کرنے والے اور صارف کے درمیان جوڑ ڈھیلا کرتا ہے، ٹیم کی خود مختاری اور آزادانہ پیمائش خریدتا ہے، اور اسی وقت کہانی کی ایک لکیر ہٹا دیتا ہے جو ہم وقت کال آپ کو صاف بتاتی: بہاؤ ابھرتا ہوا بن جاتا ہے، کسی ایک فائل کی بجائے تعاملات میں رہتا ہوا۔ انتخابی ہو کر حل کریں: ایونٹس وہاں استعمال کریں جہاں جوڑ ڈھیلا کرنا واقعی ثمر دے، جیسے ٹیم کی حدوں کے پار انضمام، بہت سے صارفین تک پھیلاؤ، بوجھ کے اچھال کی بفرنگ، اور آڈٹ۔ ہم وقت کالز وہاں رکھیں جہاں آپ کو فوری جواب اور سادہ ذہنی ماڈل چاہیے، جیسے صفحہ بنانے کے لیے ڈیٹا پڑھنا۔ بچنے کی ناکامی ہر اندرونی فنکشن کال کو ایونٹ بنانا اور اسے فن تعمیر کہنا ہے، وہی فن تعمیری فیصلہ جو باب 3.2 آپ کے اپنائے ہر نمونے سے مانگتا ہے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

اس مخصوص تعامل کے لیے، کیا ہمیں واقعی ایونٹ چاہیے، یا ہم وقت کال زیادہ صاف اور محفوظ ہوگی؟ اس سوال کو چھوڑنا ہی طریقہ ہے جس سے نظام اتفاقی پیچیدگی جمع کرتا ہے۔ ایماندار ٹیسٹ یہ ہے کہ آیا پیدا کرنے والے کو ابھی نتیجہ واپس چاہیے (کال) یا وہ ایسی حقیقت کا اعلان کر رہا ہے جس پر دوسرے اپنے وقت پر ردعمل دے سکتے ہیں (ایونٹ)۔ مخصوص تعامل لائیں، عمومی ترجیح نہیں، اور پوچھیں کہ آپ کو جوڑ ڈھیلا ہونے سے کیا ملتا ہے اور سراغ کی کون سی وضاحت چھوڑتے ہیں۔ اگر کال کرنے والا “ایونٹ” کے پروسیس ہونے کا انتظار کرتے ہوئے بلاک ہو تو آپ نے سست، ڈی بگ کرنے میں مشکل ہم وقت کال بنائی ہے اور اس سہولت کی اضافی قیمت دی ہے۔ اندرونی، ایک ہی ٹیم کے، ابھی جواب چاہیے والے تعاملات کا ڈیفالٹ براہ راست کال ہونا چاہیے؛ ایونٹس وہاں رکھیں جہاں ڈھیلا جوڑ اپنی لاگت کمائے۔
جب صارف ایک ہی ایونٹ دو بار وصول کرتا ہے تو کیا ہوتا ہے، اور کیا ہم نے واقعی اسے ٹیسٹ کیا ہے؟ کم از کم ایک بار ترسیل ضمانت دیتی ہے کہ نقلیں ہوں گی، اس لیے ہر صارف کو یکساں اثر والا ہونا چاہیے، پھر بھی یکسانیت کا دعویٰ کرنا آسان اور غلط کرنا آسان ہے۔ حقیقی صارف سے گزریں اور ٹھیک سراغ لگائیں کہ دوسری ترسیل کیسے پہچانی اور بے اثر کی جاتی ہے، چاہے یکسانیت کی کلید سے، پروسیس شدہ ایونٹس کے لاگ سے، یا فطری طور پر یکساں عمل سے۔ حقیقی ٹیسٹ کے نتائج لائیں جہاں آپ بیچ دوبارہ پہنچاتے ہیں اور تصدیق کرتے ہیں کہ دوہرے چارج، نقل ریکارڈ، یا دہرائی اطلاعات نہیں ہیں۔ ان ضمنی اثرات پر خاص توجہ دیں جو آپ کے ڈیٹا بیس سے باہر نکلتے ہیں، جیسے ای میلز، ادائیگیاں، اور تیسری پارٹی کی کالز، کیونکہ یہی وہ جگہ ہیں جہاں غیر یکساں بگز گاہکوں کو براہ راست نقصان دیتے ہیں۔ اگر آپ کی ٹیم ایسے ٹیسٹ کی طرف اشارہ نہیں کر سکتی جو نقل سے تحفظ ثابت کرے تو فرض کریں کہ آپ محفوظ نہیں۔
جب پروڈکشن میں ایونٹ کا بہاؤ ٹوٹتا ہے تو ہمیں نوٹس کرنے میں کتنا وقت لگتا ہے، اور کیا ہم ایک پیغام کا شروع سے آخر تک سراغ لگا سکتے ہیں؟ غیر ہم وقت ناکامیاں خاموش ہوتی ہیں، تو وہ صارف جو خاموشی سے پروسیس کرنا بند کر دے اس وقت تک نظر نہیں آ سکتا جب تک غائب ڈیٹا گاہک کی شکایت یا آڈٹ کا خلا نہ بن جائے۔ پوچھیں کہ آپ کا سب سے پہلا اشارہ کیا ہے، اور کیا آپ کنزیومر لیگ اور dead letter queue کی گہرائی کو ڈیش بورڈز کی بجائے الرٹنگ میٹرکس کے طور پر نگرانی کرتے ہیں جنہیں کوئی نہیں دیکھتا۔ حقیقی واقعہ یا گیم ڈے کی مشق لائیں اور وقت ناپیں کہ ایک ہم آہنگی کی ID کو پیدا کرنے والے، بروکر، اور ہر صارف کے پار فالو کرنے میں کتنا لگتا ہے۔ اگر جواب “ہم کئی سروسز پر grep کرتے ہیں اور اندازہ لگاتے ہیں” ہے تو آپ کی مشاہدہ پذیری اس پیچیدگی کے لیے تیار نہیں جو آپ نے اٹھائی۔ ضابطے کے پابند شعبوں میں یہ دوبارہ تعمیر کر سکنا کہ پیغام ٹھیک کیسے حرکت کرتا رہا اکثر تعمیل کا تقاضا ہے، تکلف نہیں۔
ہم ایسے ایونٹ اسکیما کو کیسے ارتقا دیں گے جسے بہت سی ٹیمیں پہلے ہی استعمال کر رہی ہیں بغیر ان میں سے کسی کو توڑے؟ ایونٹ کی شکل عوامی معاہدہ ہے، اور جب درجنوں صارفین اس پر انحصار کریں تو بے ضرر لگنے والی تبدیلی ان نظاموں کو توڑ سکتی ہے جن کے بارے میں آپ نے سنا بھی نہیں، دور سے، بغیر کسی کمپائلر کے انتباہ کے۔ کھنچاؤ حقیقی ہے: پیدا کرنے والے تیزی سے آگے بڑھنا اور اپنے ایونٹس صاف کرنا چاہتے ہیں، جبکہ ہر صارف شکل ہمیشہ کے لیے منجمد چاہتا ہے، اس لیے پہلے سے اتفاق کریں کہ کون سی تبدیلیاں محفوظ ہیں (اختیاری فیلڈ جوڑنا) اور کون سی نئے ورژن اور منتقلی کی کھڑکی کا تقاضا کرتی ہیں (فیلڈ ہٹانا، قسم بدلنا، نام بدلنا)۔ فی ٹاپک صارفین کی اصل فہرست، آیا آج اسکیما رجسٹری مطابقت کے قواعد نافذ کرتی ہے یا شکلیں غیر رسمی اتفاق سے بدلتی ہیں، اور منتقلی کے دوران دو ورژن کتنی دیر متوازی چل سکتے ہیں لائیں۔ بڑے انٹرپرائز یا ایجنسیوں کے پار حکومتی ڈیٹا شیئرنگ کے انتظام میں، خاموشی سے ٹوٹا اسکیما ان نظاموں میں ریکارڈ خراب کر سکتا ہے جن کے آپ مالک نہیں اور بعد میں آڈٹ کی ناکامی کے طور پر ابھر سکتا ہے، اس لیے مطابقت کے نفاذ کو شائستگی نہیں بلکہ نظم و نسق سمجھیں۔
ہماری سب سے اہم کثیر سروس ٹرانزیکشن کے لیے، ہر تلافی کا عمل دراصل کیا الٹتا ہے، اور صارفین اور آڈیٹر کون سی درمیانی حالتیں دیکھیں گے؟ ساگاز ایک جوہری ٹرانزیکشن کے تسلی بخش دھوکے کو مقامی قدموں کی ترتیب کے بدلے تجارت کرتے ہیں جو ہر ایک ناکام ہو سکتا ہے، اس لیے نظام واقعی “محفوظ مگر ادا نہیں” اور “چارج مگر روانہ نہیں” جیسی حالتوں سے گزرتا ہے ملنے سے پہلے، اور دکھاوا کرنا کہ ایسا نہیں وہ طریقہ ہے جس سے آپ ایسا ساگا بھیجتے ہیں جو پیسہ لیک کرتا یا ریکارڈ یتیم کرتا ہے۔ حقیقی عمل شروع سے آخر تک چلیں، ہر قدم کی تلافی کا نام لیں (کیا inventory چھوڑتا ہے، کیا کارڈ واپس کرتا ہے)، اور فیصلہ کریں کہ آیا نگرانی کے قابل آرکسٹریٹڈ ساگا اس ابھرتی کوریوگرافی سے بہتر ہے جسے کوئی ایک جگہ بیان نہیں کرتی۔ وہ ناکامی کی صورتیں لائیں جو آپ نے واقعی ٹیسٹ کیں، خوش گوار راستہ نہیں، اور تصدیق کریں کہ صارف کا تجربہ اور آڈٹ کا نشان “زیر عمل” اور “تلافی شدہ” حالتیں چھپانے کی بجائے ایمانداری سے دکھاتے ہیں۔ مالیات، فوائد، یا ٹیکس کے نظاموں میں ضابطہ ساز پوچھے گا کہ ہر درمیانی لمحے ریکارڈ کیسا نظر آتا تھا اور تلافی کا جوابدہ کون تھا، اس لیے ساگا کی حالتیں خود تعمیل کا آرٹیفیکٹ ہیں۔
بروکر یا ایونٹ لاگ کون چلاتا ہے، اور کیا ہم نے اسے چلانے کی حقیقی لاگت منظم متبادل کے مقابل گنی ہے؟ پیغام رسانی کی ریڑھ کی ہڈی مفت انفراسٹرکچر نہیں جو خاکے پر کھینچتے ہی ظاہر ہو جائے: کوئی اسے پیچ کرتا ہے، اس کے پارٹیشنز کی پیمائش کرتا ہے، برقراری ٹیون کرتا ہے، صبح 3 بجے پیج ہونے پر جواب دیتا ہے، اور اس کی صلاحیت اور ناکامی کے طریقوں کا مالک ہے۔ اوپن سورس بروکر کی خود میزبانی اور منظم سروس خریدنے کے درمیان جان بوجھ کر فیصلہ کریں، کنٹرول اور ڈیٹا کے مقام کو آپریشنل بوجھ اور لائسنس کی لاگت کے مقابل تولتے ہوئے، اور ایماندار رہیں کہ آیا آپ کی ٹیم کے پاس تقسیم شدہ لاگ اچھی طرح چلانے کی گہرائی ہے۔ ملکیت کی کل لاگت لائیں: آن کال کا بوجھ، مطلوبہ ماہرانہ مہارتیں، برقراری اور ذخیرے کا بل، اور بروکر کی بندش ہر منحصر بہاؤ کے ساتھ کیا کرتی ہے۔ انٹرپرائز کے لیے جواب پلیٹ فارم ٹیم کا مینڈیٹ شکل دیتا ہے، اور سرکاری ادارے کے لیے خریداری کے قواعد، ڈیٹا کی خودمختاری کے تقاضے، اور فروخت کنندہ کی قید سے بچنے کی سخت ضرورت سب سے سستے اختیار پر غالب آ سکتی ہے، اس لیے ایسی ٹیکنالوجی پر عہد کرنے سے پہلے جسے آپ ایک دہائی چلائیں گے یہ پابندیاں سامنے لائیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ آپ کا کم یاب ترین وسیلہ انجینئرنگ کی توجہ ہے، اس لیے ہم وقت رہیں جب تک پھیلاؤ واقعی تکلیف نہ دے۔ جب تین چیزوں کو ایک عمل پر ردعمل دینا ہو تو اپنا بروکر کلسٹر کھڑا کرنے کی بجائے منظم قطار یا لاگ پر ایک ایونٹ (جیسے “OrderPlaced”) شائع کریں، اور ادائیگی اور جس سے فوری جواب چاہیے اسے براہ راست کال رکھیں۔ نفیس نظر آنے کے لیے ایونٹ سورسنگ، CQRS، یا ساگاز نہ اپنائیں؛ وہ پیچیدگی چھوٹی ٹیم سے آگے نکل جائے گی اور ٹھیک اسی تکرار کو سست کرے گی جس پر آپ مقابلہ کر رہے ہیں۔

چھوٹا کاروبار۔ آپ کے پاس پیغام رسانی کا ماہر نہیں اور Kafka چلانے کی خواہش نہیں، اس لیے غیر ہم وقت انضمام کو ایسی چیز سمجھیں جو آپ خریدتے ہیں، چلاتے نہیں۔ آپ کے موجودہ ٹولز جو ایونٹس پہلے سے خارج کرتے ہیں (webhooks، آپ کے کلاؤڈ فراہم کنندہ یا SaaS پلیٹ فارمز کی اندرونی قطاریں) ان پر انحصار کریں اور منظم سروس کو ترسیل، برقراری، اور یکسانیت کی پائپ لائن کی مالک بننے دیں۔ انتخاب کو ایمانداری سے خریدنے بمقابلہ بنانے کے طور پر پیش کریں: مٹھی بھر قابل اعتماد webhook ہینڈلرز اس حسب ضرورت بروکر سے بہتر ہیں جس کا آپ عملہ نہیں دے سکتے یا صبح 3 بجے ڈی بگ نہیں کر سکتے۔

بڑا ادارہ۔ آپ کا مسئلہ بہت سی ٹیموں میں انضمام کی لاگت ہے، اس لیے ثمر منظم مشترک پلیٹ فارم ہے: پائیدار ایونٹ لاگ، نافذ شدہ مطابقت کی پالیسی کے ساتھ اسکیما رجسٹری، ٹاپک کی واضح ملکیت، اور معیاری یکسانیت اور outbox کے نمونے تاکہ ہر ٹیم انہیں دوبارہ ایجاد نہ کرے۔ یہ وہ ترتیب ہے جہاں نازک enterprise service bus یا نقطہ بہ نقطہ کڑیوں کے جال کی جگہ بدلنا حقیقی بچتوں میں مرکب ہوتا ہے، اور جہاں نظر آنے والی حیثیت کے ساتھ آرکسٹریٹڈ ساگاز آپریشنز کے عملے کو کثیر مرحلہ عمل منظم کرنے دیتے ہیں۔ مشاہدہ پذیری اور اسکیما کے نظم و نسق کی سرمایہ کاری واضح طور پر بجٹ کریں، کیونکہ اس پیمانے پر صارف کی خاموش ناکامی درجنوں نظاموں میں غائب ڈیٹا بن جاتی ہے۔

حکومت۔ پائیدار، ترتیب وار ایونٹ لاگ آڈٹ اور شفافیت کا اثاثہ ہے: یہ “یہ فیصلہ ایسے کیوں نکلا” کا جواب حقائق کی ناقابل تبدیل ترتیب سے دیتا ہے، اس لیے جہاں جوابدہی تقاضا کرے وہاں ایونٹ سورسنگ پر جھکیں۔ بین ایجنسی ڈیٹا شیئرنگ کو مستحکم ایونٹ ID پر ڈی ڈپلیکیشن کے ساتھ کم از کم ایک بار ترسیل چاہیے تاکہ دوبارہ پہنچایا گیا ریکارڈ کبھی نقل کیس نہ بنائے، اور خریداری کو ڈیٹا کی خودمختاری، بروکر کی حدوں کے افشا، اور قید کے مقابل منتقلی کی اہلیت تولنا چاہیے۔ جہاں مناسب ہو شائع کریں کہ بہاؤ کیسے کام کرتا ہے اور شہری خودکار نتیجے کو کیسے چیلنج کر سکتا ہے، اور ایونٹ لاگ کو وہ قابل دفاع ریکارڈ رکھیں جس کا معائنہ نگران ادارے مانگیں گے۔

مثالیں

اسٹارٹ اپ۔ چھوٹا ای کامرس اسٹارٹ اپ ایک ہم وقت بہاؤ سے شروع کرتا ہے: چیک آؤٹ ادائیگی کی سروس کو کال کرتا اور انتظار کرتا ہے۔ جیسے یہ بڑھتا ہے، وہ چاہتا ہے کہ آرڈر کی تصدیق کی ای میلز، inventory کی اپ ڈیٹس، اور وفاداری کا پروگرام خریداریوں پر ردعمل دیں، اور ہر ایک کو چیک آؤٹ کے اندر ایک اور ہم وقت کال کے طور پر جوڑنا چیک آؤٹ کو سست اور نازک بناتا ہے۔ ٹیم پائیدار لاگ پر ایک “OrderPlaced” ایونٹ شائع کرتی ہے اور تین آزاد صارفین کو ردعمل دینے دیتی ہے، اس لیے چیک آؤٹ پھر تیز ہو جاتا ہے اور بعد میں چوتھا ردعمل جوڑنے کو اس میں تبدیلی نہیں چاہیے۔ وہ ادائیگی کی گرفت ہم وقت رکھتے ہیں، کیونکہ آرڈر کی تصدیق سے پہلے انہیں ہاں یا نہیں کا جواب چاہیے، جو ان کے سائز پر لکیر کھینچنے کی بالکل درست جگہ ہے۔

بڑا ادارہ۔ ایک عالمی بیمہ کار نقطہ بہ نقطہ انضمام اور پرانے enterprise service bus (ESB) میں ڈوب رہا ہے، مرکزی مرکز جس سے ہر نظام گزرتا ہے اور جو رکاوٹ اور ناکامی کا واحد نقطہ بن چکا ہے۔ وہ پائیدار ایونٹ لاگ پر منتقل ہوتا ہے جہاں ہر ڈومین اپنے حقائق شائع کرتا ہے (پالیسی جاری، دعویٰ دائر، ادائیگی ہوئی) اور استعمال کرنے والی ٹیمیں اس کو سبسکرائب کرتی ہیں جو انہیں چاہیے۔ دعووں کا ساگا، جو آرکسٹریٹڈ ہے تاکہ آپریشنز کا عملہ ہر دعوے کی حیثیت دیکھ سکے، ناکام ہونے والے قدموں کی تلافیوں کے ساتھ کثیر مرحلہ تصفیہ ہم آہنگ کرتا ہے۔ اسکیما رجسٹری پالیسی کی ٹیم کو اپنے ایونٹس کو چالیس استعمال کرنے والے نظاموں کے پار ہم آہنگ تعیناتی کے بغیر ارتقا دینے دیتی ہے، ٹھیک وہ نازکی جو پرانا ESB مسلط کرتا تھا۔

حکومت۔ قومی ٹیکس ایجنسی کو شہریوں اور آڈیٹرز کو “میرا تشخیص ایسے کیوں نکلا” کا قابل دفاع جواب دینا ہے۔ وہ تشخیص کے ڈومین کو ایونٹ سورسنگ سے ماڈل کرتی ہے، تاکہ ہر تبدیلی ترتیب وار لاگ میں ناقابل تبدیل ایونٹ ہو اور موجودہ تشخیص ان ایونٹس کا دوبارہ چلانا ہو؛ جب شہری رقم پر تنازع کرتا ہے تو کیس ورکر کسی بھی ماضی کی تاریخ پر ٹھیک حالت دوبارہ تعمیر کرتا ہے اور حقائق کی وہ ترتیب دکھاتا ہے جس نے اسے پیدا کیا۔ بین ایجنسی ڈیٹا شیئرنگ کم از کم ایک بار ترسیل والے پائیدار ٹاپکس پر چلتی ہے، اور ہر ایجنسی کا صارف ایونٹ ID پر ڈی ڈپلیکیٹ کرتا ہے تاکہ دوبارہ پہنچایا گیا ریکارڈ کبھی نقل کیس نہ بنائے۔ ایونٹ لاگ ساتھ ہی آڈٹ کا نشان بھی ہے جو نگران ادارے مانگتے ہیں، تعمیل کی ذمہ داری کو ڈیزائن کی ضمنی پیداوار بنا دیتا ہے۔

کاروباری جواز: محرکات، ROI اور TCO

ایونٹ پر مبنی فن تعمیر کی واپسی پر ایک چیز غالب ہے: وقت کے ساتھ انضمام کی لاگت۔ نقطہ بہ نقطہ انضمام لاگت کو روابط کی تعداد کے ساتھ بڑھاتا ہے، جو نظاموں کی تعداد سے تیز بڑھتی ہے، اس لیے انضمام وہ محصول بن جاتا ہے جو آپ کی ترسیل کی صلاحیت کھاتا ہے۔ ایونٹس اسے چپٹا کرتے ہیں، کیونکہ ٹیمیں حقائق کی مشترک دھار سے ضم ہوتی ہیں، نیا صارف سبسکرائب کر کے شامل ہوتا ہے، اور پیدا کرنے والے ورژن شدہ اسکیما کے پیچھے ارتقا کرتے ہیں، تو اگلے انضمام کی حاشیائی لاگت تیزی سے گرتی ہے۔ قیادت کو بتانے کے لیے بنیادی ROI کی کہانی یہی ہے: خام کارکردگی نہیں، بلکہ بہت سی ٹیموں میں تبدیلی کی لاگت میں مرکب کمی۔

ملکیت کی کل لاگت ایمانداری سے بیان کریں تاکہ آپ پر یقین ہو۔ آپ چلانے کے لیے بروکر کا انفراسٹرکچر، برقرار رکھنے کے لیے اسکیما کا نظم و نسق، اور آپریشنل سیکھنے کا کھڑا منحنی اٹھاتے ہیں، کیونکہ غیر ہم وقت نظاموں کو ڈی بگ کرنا واقعی مشکل ہے، اس لیے مشاہدہ پذیری کی سرمایہ کاری کا بجٹ پیشگی رکھیں۔ انہیں اس لاگت کے مقابل تولیں جو ایونٹس وہاں اپنانے کی نہ کرنے پر آتی ہے جہاں وہ موزوں ہیں: منجمد انضمام کی تہہ جہاں ہر تبدیلی کئی ٹیموں کی ہم آہنگی کا منصوبہ ہے، پرانا ESB جو ایسی رکاوٹ بن چکا ہے جسے چھونے کی کوئی ہمت نہیں کرتا، اور پرانی صلاحیتوں کو چھیڑے بغیر نئی جوڑنے کی نااہلی۔ بنیادی نقطہ بہ نقطہ تاروں کی جگہ لینے والے انٹرپرائز اور پائیدار آڈٹ کے نشان بنانے والی حکومت کے لیے ثمر وہاں سب سے مضبوط ہے جہاں آڈٹ اور جوڑ ڈھیلا کرنے کی ضرورتیں حقیقی ہیں۔ جہاں وہ ضرورتیں نہ ہوں وہاں ایماندار جواب یہ ہے کہ سادہ ہم وقت ڈیزائن کی TCO کم ہے، اور آپ کو یہ کہنا چاہیے۔

ضد نمونے اور خامیاں

بھیس بدلا تقسیم شدہ یک سنگی نظام۔ سروسز جنہیں سب کو ایک ساتھ تعینات کرنا ہو اور جو ایک دوسرے کے اندرونی ایونٹس پر منحصر ہوں۔ آپ نے بروکر جوڑا مگر جوڑ رکھا، تو آپ کے پاس دونوں اسالیب کے نقصانات ہیں۔
کمانڈز کے طور پر ایونٹس۔ ایسے “ایونٹس” شائع کرنا جن کا مطلب دراصل “براہ کرم میرے لیے یہ مخصوص کام کرو” ہے، اضافی لیٹنسی اور بدتر سراغ پذیری کے ساتھ سخت جوڑ دوبارہ بناتے ہوئے۔
بالکل ایک بار ترسیل فرض کرنا۔ ایسے صارفین جو ٹوٹتے، دو بار چارج کرتے، یا ریکارڈ نقل کرتے ہیں جب بروکر لازماً پیغام دوبارہ پہنچاتا ہے۔
ہر جگہ ایونٹ سورسنگ۔ سادہ create-read-update-delete ڈومینز پر ایونٹ سورسنگ اور CQRS لاگو کرنا جنہیں تاریخ کبھی نہیں چاہیے تھی، فائدے کے بغیر کھڑی پیچیدگی خریدتے ہوئے۔
اسکیما کے نظم و نسق کا فقدان۔ پیدا کرنے والے ایونٹ کی شکلیں آزادانہ بدلتے ہیں، مطابقت کی جانچ کے بغیر نیچے کے صارفین کو دور سے توڑتے ہوئے۔
outbox کو نظر انداز کرنا۔ ڈیٹا بیس میں لکھنا اور ایونٹ شائع کرنا دو الگ قدموں کے طور پر، اس لیے ان کے بیچ کا کریش خاموشی سے ایونٹس کھوتا یا فرضی خارج کرتا ہے۔
dead letter کی ہینڈلنگ نہیں۔ ایک زہریلا پیغام پارٹیشن کو بلاک کر رہا ہو، یا ناکام پیغامات بغیر کسی قطار کے غائب ہو جائیں جو انہیں پکڑ کر معائنہ کرے۔
غیر مرئی بہاؤ۔ ہم آہنگی کی IDs، کنزیومر لیگ کے الرٹس، اور ٹریسنگ کے بغیر غیر ہم وقت پروسیسنگ، تو ناکامیاں خاموش رہتی ہیں جب تک غائب ڈیٹا نہ بن جائیں۔

پختگی کا ماڈل

سطح 1، آغاز: انضمام فی البدیہہ نقطہ بہ نقطہ کالز ہے، یا بروکر موجود ہے مگر ہم وقت درخواست/جواب کی طرح استعمال ہوتا ہے۔ نقلیں صارفین کو توڑتی ہیں، کوئی اسکیما کا نظم یا ہاپس کے پار سراغ نہیں، اور ناکام پیغامات خاموشی سے غائب ہو جاتے ہیں۔
سطح 2، ترقی: کچھ بہاؤ کے لیے بروکر یا لاگ حقیقی استعمال میں ہے، اور چند ٹیموں کے پاس بنیادی عمل ہیں: صارفین یکساں ہونے لگے ہیں اور dead letter queues کچھ ناکامیاں پکڑتی ہیں۔ مگر طریقہ ٹیموں میں غیر مستقل ہے، ایونٹس اور کمانڈز اب بھی گڈمڈ ہیں، اسکیما غیر رسمی اتفاق سے بدلتے ہیں، اور مشاہدہ پذیری ہلکی ہے۔
سطح 3، معیار بندی: ایونٹس، کمانڈز، اور پیغامات ادارے بھر میں جان بوجھ کر الگ کیے جاتے ہیں۔ صارفین معیار کے طور پر یکساں ہیں، اسکیما دستاویزی اور نافذ شدہ مطابقت کی پالیسی کے ساتھ رجسٹری میں رہتے ہیں، اور transactional outbox ترسیل کی ضمانت دیتا ہے۔ تلافیوں والے ساگاز کثیر سروس ٹرانزیکشنز سنبھالتے ہیں، ہم آہنگی کی IDs ہر ہاپ سے گزرتی ہیں، اور یہ نمونے لکھے ہیں اور ہر ٹیم پر چھوڑنے کی بجائے مستقل لاگو ہیں۔
سطح 4، انتظام: ایونٹ پلیٹ فارم ڈیٹا سے بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ کنزیومر لیگ، dead letter queue کی گہرائی، دوبارہ ترسیل کی شرحیں، اور پروسیسنگ کی لیٹنسی متفقہ حدوں کے ساتھ الرٹنگ میٹرکس کے طور پر ٹریک ہوتی ہیں، ایسے ڈیش بورڈز نہیں جنہیں کوئی نہیں دیکھتا؛ پیدا کرنے والے کے تبدیلی بھیجنے سے پہلے اسکیما کی مطابقت خود بخود توثیق ہوتی ہے؛ دوبارہ چلانا، ناکامی کی ہینڈلنگ، اور یکسانیت مقررہ تال پر ٹیسٹ ہوتی ہیں بجائے امید کیے جانے کے۔ دیا گیا تعامل ایونٹ ہو یا ہم وقت کال، یہ فیصلہ شہادت پر ہوتا ہے، اور ہر بروکر کی صلاحیت، برقراری کی لاگت، اور اعتبار کا اہداف کے مقابل ریویو ہوتا ہے۔
سطح 5، ہم آہنگی: ایونٹ پر مبنی اور ہم وقت اسالیب فی تعامل فطری طور پر چنے جاتے ہیں، اور ایونٹ سورسنگ اور CQRS ٹھیک وہاں لاگو ہوتے ہیں جہاں آڈٹ اور سوال کی ضروریات جواز دیں اور کہیں نہیں۔ غیر ہم وقت بہاؤ اتنے ہی قابل مشاہدہ ہیں جتنے ہم وقت، ضروریات بدلنے پر پلیٹ فارم مسلسل بہتر ہوتا ہے (مردہ ٹاپکس ریٹائر کرنا، اسکیما کے نظم و نسق کو ارتقا دینا، پارٹیشنز دوبارہ متوازن کرنا)، اور پیغام رسانی وسیع تر فن تعمیر اور آڈٹ کی حکمت عملی سے مربوط ہے تاکہ ادارہ کاروبار اور اس کی ذمہ داریوں کے بدلنے پر اپنے ایونٹ کے ڈیزائن کو ڈھالے۔

بحث کے لیے خیالات

آپ کے موجودہ “ایونٹس” میں سے کون سے خفیہ طور پر کمانڈز ہیں، اور انہیں ایمانداری سے ماڈل کر کے آپ کون سا جوڑ ہٹائیں گے؟
اگر آپ کل ایونٹس کا پورا دن اپنے صارفین کے ذریعے دوبارہ چلائیں تو کیا ٹوٹے گا، اور یہ آپ کی یکسانیت اور دوبارہ چلانے کی حفاظت کے بارے میں کیا بتاتا ہے؟
آپ کے ڈومین کے کن حصوں کو واقعی ایونٹ سورسنگ کا آڈٹ کا نشان چاہیے، اور کون سے سادہ حالت ہیں جنہیں آپ سورسنگ سے صرف پیچیدہ کریں گے؟
آپ پرانے enterprise service bus یا نقطہ بہ نقطہ انضمام کے جال سے خطرناک بڑے دھماکے والے کٹ اوور کے بغیر کیسے منتقل ہوں گے؟
آپ کے سب سے اہم کثیر سروس عمل کے لیے، کیا یہ تلافیوں کے ساتھ حقیقی آرکسٹریٹڈ ساگا ہے، یا ابھرتی کوریوگرافی جسے کوئی ایک جگہ بیان نہیں کرتی؟

اہم نکات

ایونٹ پر مبنی فن تعمیر جوڑ ڈھیلا کرنے، آزادانہ پیمائش، دوبارہ چلانے، اور آڈٹ کا نشان خریدتا ہے، اور قابل فہم ہونے اور آپریشنل پیچیدگی کی لاگت لیتا ہے، اس لیے اسے فی تعامل وہاں چنیں جہاں فائدہ حقیقی ہو۔
ایونٹس (جو ہو چکے حقائق)، کمانڈز (عمل کی درخواستیں)، اور پیغامات (لفافہ) الگ رکھیں، کیونکہ الجھن حقیقی جوڑ کی غلطیاں پیدا کرتی ہے۔
کم از کم ایک بار ترسیل کے لیے ڈیزائن کریں اور ہر صارف کو یکساں اثر والا بنائیں؛ بالکل ایک بار ترسیل افسانہ ہے، اور بالکل ایک بار اثرات انجینئرنگ کی کامیابی ہیں۔
ترتیب فی پارٹیشن ہے، اسکیما معاہدے ہیں جو رجسٹری میں ہونے چاہئیں، اور outbox، dead letter queues، اور بیک پریشر وہ پائپ لائن ہیں جو پیغام رسانی کو پروڈکشن کے لیے تیار بناتی ہیں۔
دو مرحلہ کمٹ کی بجائے تلافیوں والے ساگاز استعمال کریں، اور ایونٹ سورسنگ اور CQRS تک صرف وہاں پہنچیں جہاں آڈٹ اور سوال کی ضروریات ان کی کھڑی لاگت کا جواز دیں۔
غیر ہم وقت بہاؤ ناکام ہونے پر خاموش ہوتے ہیں، اس لیے ہم آہنگی کی IDs، کنزیومر لیگ کی نگرانی، اور شروع سے آخر تک ٹریسنگ قابل چلانے اور غیر مرئی نظام کا فرق ہیں۔

حوالہ جات اور مزید مطالعہ

Martin Kleppmann, Designing Data-Intensive Applications
Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns
Chris Richardson, Microservices Patterns (sagas, transactional outbox, CQRS)
Sam Newman, Building Microservices
Ben Stopford, Designing Event-Driven Systems
Adam Bellemare, Building Event-Driven Microservices
Vaughn Vernon, Implementing Domain-Driven Design (event sourcing and CQRS)
Martin Fowler, “Event Sourcing” and “CQRS” (martinfowler.com articles)
Hector Garcia-Molina and Kenneth Salem, “Sagas” (1987)