3.3 تقسیم شدہ نظام

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

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

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

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

بنیادی اصول

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

سفارشات

CAP اور PACELC سے مطابقت پر استدلال کریں

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

یکسانیت، ٹائم آؤٹ، دوبارہ کوششیں، اور بیک آف ساتھ بنائیں

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

زنجیری ناکامیاں روکنے کے لیے سرکٹ بریکرز اور بلک ہیڈز جوڑیں

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

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

آپ عموماً متعدد سروسز یا ڈیٹا بیس کے پار ایک ACID (Atomicity, Consistency, Isolation, Durability) ٹرانزیکشن نہیں رکھ سکتے۔ تقسیم شدہ دو مرحلہ کمٹ سست ہے، وسائل کو لاک کرتا ہے، اور دستیابی کاٹتا ہے۔ اس کی بجائے ساگا پیٹرن استعمال کریں۔ کاروباری ٹرانزیکشن کو مقامی ٹرانزیکشنز کے سلسلے کے طور پر ماڈل کریں، ہر ایک ایونٹ شائع کرتا ہے جو اگلے کو متحرک کرتا ہے، ہر قدم کے لیے تلافی کا عمل کے ساتھ جو اسے الٹ دے اگر بعد کا قدم ناکام ہو۔ ساگاز دو انداز میں آتے ہیں۔ کوریوگرافی میں سروسز ایک دوسرے کے ایونٹس پر ردعمل دیتی ہیں، کوئی مرکزی کنٹرولر نہیں۔ آرکسٹریشن میں مرکزی کوآرڈینیٹر قدم چلاتا ہے، جس پر استدلال اور نگرانی آسان ہے۔ ساگاز حتمی مطابقت کو گلے لگاتے ہیں: نظام درمیانی حالتوں سے گزرتا ہے اور پھر ملتا ہے۔ اس لیے صارف کا تجربہ اور آڈٹ کا نشان “زیر عمل” اور “تلافی شدہ” حالتوں کا حساب رکھنے کے لیے ڈیزائن کریں۔

بالکل ایک بار کو کم از کم ایک بار جمع ڈی ڈپلیکیشن سمجھیں

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

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

مشاہدہ پذیری کے تین ستون اپنائیں، سروس کی حدوں کے پار مربوط۔ ہر ہاپ سے ٹریس/ہم آہنگی کی ID گزاریں، تاکہ آپ ایک صارف کی درخواست کو ان تمام سروسز کے پار فالو کر سکیں جنہیں وہ چھوتی ہے (تقسیم شدہ ٹریسنگ)۔ فی سروس اور فی انحصار منظم میٹرکس خارج کریں (لیٹنسی کے پرسنٹائل، خرابی کی شرحیں، سیرابی، تھرو پٹ)۔ ہم آہنگی کی ID لے جانے والے منظم لاگز خارج کریں۔ یہ سب سروس کی سطح کے مقاصد طے کرنے اور ان علامات پر الرٹ کرنے کے لیے استعمال کریں جو صارفین دراصل محسوس کرتے ہیں، جیسے خرابی کی شرح اور لیٹنسی، صرف انفرادی مشین کی صحت پر نہیں۔ تقسیم شدہ نظام میں مشاہدہ پذیری اختیاری ٹولنگ نہیں۔ یہ جزوی ناکامی کے تحت رویہ سمجھنے کا واحد طریقہ ہے۔

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مثالیں

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

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

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

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

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

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

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

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

پختگی کا ماڈل

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

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

1. آپ کے نازک عملیات میں سے کون سے آج واقعی یکساں اثر والے ہیں، اور کون سے خاموشی سے نہیں؟
2. ہر بڑے ڈیٹا کے بہاؤ کے لیے، کیا آپ کی ٹیم مطابقتی ماڈل اور ترسیل کی ضمانت یاد سے بتا سکتی ہے؟
3. آپ کی آخری زنجیری بندش میں سرکٹ بریکر کہاں اسے روک دیتا؟
4. ایک ناکام درخواست کو ان تمام سروسز کے پار سراغ لگانے میں فی الحال کتنا وقت لگتا ہے جنہیں وہ چھوتی ہے؟
5. آپ کے “تقسیم شدہ ٹرانزیکشنز” میں سے کون سے دراصل قسمت پر انحصار کرتے ہیں، اور کون سے تلافیوں کے ساتھ حقیقی ساگاز ہیں؟
6. اگر آپ کا پیغام کا بروکر ایک گھنٹے تک ہر پیغام دو بار دوبارہ پہنچائے تو کیا ٹوٹے گا؟

اہم نکات

• فرض کریں کہ نیٹ ورک ناقابل اعتماد ہے اور ناکامیاں جزوی ہیں؛ ہر دور دراز تعامل کو سست روی، نقصان، دہرانے، اور ترتیب بدلنے کے لیے ڈیزائن کریں۔
• CAP/PACELC سے مطابقت بمقابلہ دستیابی کا فیصلہ ہر عمل کے لیے کریں؛ ہر بہاؤ کے فراہم کردہ ماڈل کو دستاویزی کریں۔
• یکسانیت، ٹائم آؤٹ، محدود دوبارہ کوششیں، اور جٹر کے ساتھ بیک آف ایک پیکج ہیں؛ باقی تین کے بغیر کبھی دوبارہ کوششیں نہ اپنائیں۔
• سرکٹ بریکرز اور بلک ہیڈز ناکامیاں روکتے ہیں؛ تلافیوں والے ساگاز ناقابل عمل تقسیم شدہ ٹرانزیکشنز کی جگہ لیتے ہیں۔
• ترسیل کو کم از کم ایک بار سمجھیں اور بالکل ایک بار اثرات حاصل کرنے کے لیے پروسیسنگ کو یکساں بنائیں۔
• مربوط ٹریسنگ، میٹرکس، اور لاگز تقسیم شدہ بہاؤ کو سمجھنے اور چلانے کا واحد طریقہ ہیں۔

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

• Martin Kleppmann, Designing Data-Intensive Applications
• Andrew Tanenbaum and Maarten van Steen, Distributed Systems: Principles and Paradigms
• Michael Nygard, Release It!: Design and Deploy Production-Ready Software
• Sam Newman, Building Microservices
• Chris Richardson, Microservices Patterns (sagas, transactional messaging)
• Eric Brewer, “CAP Twelve Years Later” and Daniel Abadi on PACELC
• Leslie Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System”
• Cindy Sridharan, Distributed Systems Observability
• Nassim Nicholas Taleb’s notion of antifragility (as applied by resilience-engineering literature)