تقسیم شدہ نظاموں میں قابل اعتماد پیغام رسانی

دوہری لکھنے کا مسئلہ ایک قابل اعتماد، انتہائی دستیاب، توسیع پذیر تقسیم شدہ نظام کی تعمیر کے لیے مخصوص تکنیکوں، اصولوں اور نمونوں کی پابندی کی ضرورت ہوتی ہے۔ اس طرح کے نظاموں کے ڈیزائن میں متعدد چیلنجوں سے نمٹنا شامل ہے۔ سب سے زیادہ مروجہ اور بنیادی مسائل میں ہے۔ دوہری تحریر کا مسئلہ ایک چیلنج ہے جو تقسیم شدہ نظاموں میں پیدا ہوتا ہے، بنیادی طور پر جب متعدد ڈیٹا کے ذرائع یا ڈیٹا بیس کے ساتھ کام کرتے ہیں جنہیں مطابقت پذیر رکھنے کی ضرورت ہوتی ہے۔ یہ اس بات کو یقینی بنانے میں دشواری کا حوالہ دیتا ہے کہ ڈیٹا کی تبدیلیاں مختلف ڈیٹا اسٹورز، جیسے ڈیٹا بیسز یا کیشز پر مستقل طور پر لکھی جاتی ہیں، بغیر ڈیٹا کی عدم مطابقت، تنازعات، یا کارکردگی کی رکاوٹوں جیسے مسائل کو متعارف کروائے۔ "دوہری تحریری مسئلہ" مائیکرو سروسز آرکیٹیکچر اور پیٹرن ڈیٹا بیس فی سروس آپ کو بہت سے فوائد لاتا ہے، جیسے آزاد تعیناتی اور اسکیلنگ، الگ تھلگ ناکامیاں، اور ترقی کی رفتار میں ممکنہ اضافہ۔ تاہم، آپریشنز کے لیے متعدد مائیکرو سروسز میں تبدیلی کی ضرورت ہوتی ہے، جو آپ کو اس مسئلے سے نمٹنے کے لیے ایک قابل اعتماد حل کے بارے میں سوچنے پر مجبور کرتی ہے۔ تقریباً ایک حقیقی مثال آئیے ایک ایسے منظر نامے پر غور کریں جس میں ہمارے ڈومین میں قرض کی درخواستیں قبول کرنا، ان کا اندازہ لگانا، اور پھر صارفین کو اطلاع کے انتباہات بھیجنا شامل ہے۔ واحد ذمہ داری کے اصول، کونوے کے قانون، اور ڈومین سے چلنے والے ڈیزائن کے نقطہ نظر کی روح میں، کئی واقعات کے طوفانی سیشنوں کے بعد، پورے ڈومین کو تین ذیلی ڈومینز میں تقسیم کر دیا گیا تھا جس میں واضح حدود، ڈومین ماڈلز، اور ہر جگہ موجود سیاق و سباق کی وضاحت کی گئی تھی۔ قرض کی نئی درخواستوں کو آن بورڈنگ اور مرتب کرنے کا کام سونپا جاتا ہے۔ نظام ان ایپلی کیشنز کا جائزہ لیتا ہے اور فراہم کردہ ڈیٹا کی بنیاد پر فیصلے کرتا ہے۔ یہ تشخیصی عمل، بشمول KYC/KYB، اینٹی فراڈ، اور کریڈٹ رسک چیک، وقت طلب ہوسکتا ہے، جس کے لیے بیک وقت ہزاروں درخواستوں کو ہینڈل کرنے کی اہلیت کی ضرورت ہوتی ہے۔ نتیجتاً، اس فعالیت کو اس کے اپنے ڈیٹا بیس کے ساتھ ایک سرشار مائیکرو سروس کو سونپا گیا ہے، جس سے آزاد اسکیلنگ کی اجازت دی گئی ہے۔ سب سے پہلے دوسرا مزید برآں، ان سب سسٹمز کا انتظام دو مختلف ٹیموں کے ذریعے کیا جاتا ہے، ہر ایک کی اپنی ریلیز سائیکل، سروس لیول ایگریمنٹس (SLA) اور اسکیل ایبلٹی کی ضروریات۔ ، صارفین کو الرٹ بھیجنے کے لیے ایک خصوصی نوٹیفکیشن سروس موجود ہے۔ آخر میں یہاں سسٹم کے بنیادی استعمال کے معاملے کی ایک بہتر وضاحت ہے: ایک صارف قرض کی درخواست جمع کراتا ہے۔ لون ایپلیکیشن سروس نئی درخواست کو "پینڈنگ" اسٹیٹس کے ساتھ ریکارڈ کرتی ہے اور درخواست کو اسیسمنٹ سروس کو بھیج کر تشخیص کا عمل شروع کرتی ہے۔ اسسمنٹ سروس آنے والی قرض کی درخواست کا جائزہ لیتی ہے اور اس کے بعد قرض کی درخواست سروس کو فیصلے سے آگاہ کرتی ہے۔ فیصلہ موصول ہونے پر، لون ایپلیکیشن سروس اس کے مطابق قرض کی درخواست کی حیثیت کو اپ ڈیٹ کرتی ہے اور صارف کو نتائج سے آگاہ کرنے کے لیے نوٹیفیکیشن سروس کو متحرک کرتی ہے۔ نوٹیفیکیشن سروس اس درخواست پر کارروائی کرتی ہے اور گاہک کی ترتیبات کے مطابق، ای میل، ایس ایم ایس، یا دیگر ترجیحی مواصلاتی طریقوں کے ذریعے صارف کو اطلاعات بھیجتی ہے۔ یہ پہلی نظر میں ایک بہت ہی آسان اور قدیم نظام ہے، لیکن آئیے اس بات پر غور کریں کہ لون ایپلیکیشن سروس کس طرح سبمٹ لون ایپلیکیشن کمانڈ پر کارروائی کرتی ہے۔ ہم خدمت کے تعامل کے لیے دو طریقوں پر غور کر سکتے ہیں: اس نقطہ نظر میں، سروس اپنے مقامی ڈیٹا بیس (کمیٹ) کو اپ ڈیٹ کرتی ہے اور پھر دوسری خدمات کے لیے ایک واقعہ یا پیغام شائع کرتی ہے۔ پہلے-مقامی-کمٹ-پھر-پبلش: اس کے برعکس، اس طریقہ کار میں مقامی ڈیٹا بیس میں تبدیلیاں کرنے سے پہلے ایک واقعہ یا پیغام شائع کرنا شامل ہے۔ پہلے-پبلش-پھر-مقامی-کمیٹ: دونوں طریقوں میں اپنی خامیاں ہیں اور تقسیم شدہ نظاموں میں مواصلات کے لیے صرف جزوی طور پر ناکام محفوظ ہیں۔ یہ پہلی نقطہ نظر کو لاگو کرنے کا ایک ترتیب خاکہ ہے۔ اس منظر نامے میں، لون ایپلیکیشن سروس اپروچ کو استعمال کرتی ہے، جہاں یہ پہلے لین دین کا ارتکاب کرتی ہے اور پھر کسی دوسرے سسٹم کو اطلاع بھیجنے کی کوشش کرتی ہے۔ تاہم، یہ عمل ناکامی کے لیے حساس ہے اگر، مثال کے طور پر، نیٹ ورک کے مسائل ہیں، اسسمنٹ سروس دستیاب نہیں ہے، یا لون ایپلیکیشن سروس کو میموری سے باہر (OOM) کی خرابی اور کریش کا سامنا کرنا پڑتا ہے۔ ایسی صورتوں میں، پیغام گم ہو جائے گا، نئے قرض کی درخواست کے نوٹس کے بغیر تشخیص چھوڑ کر، جب تک کہ اضافی اقدامات نافذ نہ ہوں۔ فرسٹ-لوکل-کمیٹ-پھر-پبلش اور دوسرا۔ منظر نامے میں، لون ایپلیکیشن سروس کو زیادہ اہم خطرات کا سامنا ہے۔ یہ اسیسمنٹ سروس کو کسی نئی ایپلیکیشن کے بارے میں مطلع کر سکتا ہے لیکن ڈیٹا بیس کے مسائل، میموری کی خرابیاں، یا کوڈ بگز جیسے مسائل کی وجہ سے مقامی طور پر اس اپ ڈیٹ کو محفوظ کرنے میں ناکام ہو جاتا ہے۔ یہ نقطہ نظر اعداد و شمار میں اہم تضادات کا باعث بن سکتا ہے، جو سنگین مسائل کا سبب بن سکتا ہے، اس بات پر منحصر ہے کہ لون ریویو سروس آنے والی درخواستوں کو کیسے ہینڈل کرتی ہے۔ پہلی اشاعت-پھر-مقامی-کمٹ کے لہذا، ہمیں ایک ایسے حل کی نشاندہی کرنی چاہیے جو بیرونی صارفین کو واقعات کی اشاعت کے لیے ایک مضبوط طریقہ کار پیش کرے۔ لیکن، ممکنہ حل تلاش کرنے سے پہلے، ہمیں سب سے پہلے یہ واضح کرنا چاہیے کہ تقسیم شدہ نظاموں میں پیغام کی ترسیل کی ضمانتوں کی کون سی قسمیں حاصل کی جا سکتی ہیں۔ پیغام کی ترسیل کی ضمانت دیتا ہے۔ چار قسم کی ضمانتیں ہیں جو ہم حاصل کر سکتے ہیں۔ کوئی ضمانت نہیں۔ اس بات کی کوئی گارنٹی نہیں کہ پیغام منزل تک پہنچ جائے گا۔ کا نقطہ نظر بالکل اسی بارے میں ہے۔ صارفین کو ایک بار، کئی بار، یا کبھی بھی پیغامات موصول ہو سکتے ہیں۔ پہلے-مقامی-کمیٹ-پھر-پبلش زیادہ سے زیادہ ایک بار ترسیل زیادہ سے زیادہ ایک بار ڈیلیوری کا مطلب ہے کہ پیغام زیادہ سے زیادہ 1 بار منزل تک پہنچایا جائے گا۔ نقطہ نظر کو اس طرح لاگو کیا جا سکتا ہے اور ساتھ ہی ایک قدر کے ساتھ کوششوں کی دوبارہ کوشش کی پالیسی کے ساتھ۔ پہلے-مقامی-کمیٹ-پھر-پبلش کے کم از کم ایک بار ڈیلیوری\صارفین ہر پیغام کو وصول کریں گے اور اس پر کارروائی کریں گے لیکن ایک سے زیادہ بار ایک ہی پیغام موصول ہو سکتا ہے۔ بالکل ایک بار ڈیلیوری\ بالکل ایک بار ڈیلیوری کا مطلب ہے کہ صارف کو ایک بار مؤثر طریقے سے پیغام موصول ہوگا۔ تکنیکی طور پر، کافکا کے لین دین اور پروڈیوسر اور صارف کے مخصوص غیر موثر نفاذ کے ساتھ حاصل کرنا ممکن ہے۔ زیادہ تر معاملات میں، ڈیلیوری کی ضمانت بہت سے مسائل کو یقینی بناتی ہے اس بات کو یقینی بنا کر کہ پیغامات کم از کم ایک بار ڈیلیور کیے جائیں، لیکن صارفین کو بے اختیار ہونا چاہیے۔ تاہم، نیٹ ورک کی ناگزیر ناکامیوں کے پیش نظر، پروڈیوسر کی ضمانتوں سے قطع نظر، ڈپلیکیٹ پیغامات پر کارروائی کرنے سے بچنے کے لیے تمام صارفین کی منطق کو قابل عمل ہونا چاہیے۔ لہذا، یہ ضرورت اتنی زیادہ خرابی نہیں ہے کیونکہ یہ حقیقت کی عکاسی کرتی ہے۔ 'کم از کم ایک بار' حل اس مسئلے کے بہت سارے حل ہیں، جن کے اپنے فوائد اور نقصانات ہیں۔ دو فیز کمٹ ویکیپیڈیا کے مطابق، ٹو فیز کمٹ (2PC) تقسیم شدہ لین دین کا پروٹوکول ہے جسے کمپیوٹر سائنس اور ڈیٹا بیس مینجمنٹ سسٹم میں استعمال کیا جاتا ہے تاکہ تقسیم شدہ لین دین کی مستقل مزاجی اور وشوسنییتا کو یقینی بنایا جا سکے۔ یہ ایسے حالات کے لیے ڈیزائن کیا گیا ہے جہاں متعدد وسائل (مثلاً، ڈیٹا بیس) کو ایک ہی لین دین میں حصہ لینے کی ضرورت ہوتی ہے، اور یہ یقینی بناتا ہے کہ یا تو ان میں سے سبھی لین دین کا ارتکاب کرتے ہیں یا سبھی اسے منسوخ کر دیتے ہیں، اس طرح ڈیٹا کی مستقل مزاجی کو برقرار رکھا جاتا ہے۔ یہ بالکل وہی لگتا ہے جس کی ہمیں ضرورت ہے، لیکن دو فیز کمٹ میں کئی خرابیاں ہیں: اگر ایک حصہ لینے والا وسیلہ غیر جوابدہ ہو جاتا ہے یا ناکامی کا تجربہ کرتا ہے، تو مسئلہ حل ہونے تک پورے عمل کو روکا جا سکتا ہے۔ یہ ممکنہ کارکردگی اور دستیابی کے مسائل کا باعث بن سکتا ہے۔ دو فیز کمٹ بلٹ ان فالٹ ٹولرنس میکانزم فراہم نہیں کرتا ہے۔ یہ ناکامیوں کو سنبھالنے کے لیے بیرونی میکانزم یا دستی مداخلت پر انحصار کرتا ہے۔ تمام جدید ڈیٹا بیس دو فیز کمٹ کی حمایت نہیں کرتے ہیں۔ مشترکہ ڈیٹا بیس مائیکرو سروسز فن تعمیر کا سب سے واضح حل ایک پیٹرن (یا کبھی کبھی اینٹی پیٹرن) کا اطلاق کرنا ہے — ایک مشترکہ ڈیٹا بیس۔ یہ نقطہ نظر بہت بدیہی ہے اگر آپ کو مختلف ڈیٹا بیس میں متعدد ٹیبلز پر لین دین کی مستقل مزاجی کی ضرورت ہے، تو ان مائیکرو سروسز کے لیے صرف ایک مشترکہ ڈیٹا بیس استعمال کریں۔ اس نقطہ نظر کی خرابیوں میں ناکامی کے ایک نقطہ کو متعارف کرانا، آزاد ڈیٹا بیس اسکیلنگ کو روکنا، اور مخصوص ضروریات اور استعمال کے معاملات کے لیے بہترین موزوں مختلف ڈیٹا بیس حل استعمال کرنے کی صلاحیت کو محدود کرنا شامل ہے۔ مزید برآں، مائیکرو سروسز کوڈ بیسز میں تبدیلیاں اس طرح کی تقسیم شدہ لین دین کی حمایت کے لیے ضروری ہوں گی۔ ٹرانزیکشنل آؤٹ باکس ' ' ایک ایسا ڈیزائن پیٹرن ہے جو تقسیم شدہ نظاموں میں استعمال کیا جاتا ہے تاکہ پیغام کے قابل اعتماد پھیلاؤ کو یقینی بنایا جا سکے، یہاں تک کہ ناقابل بھروسہ پیغام رسانی کے نظام کے باوجود۔ اس میں ایونٹس کو ایک نامزد 'OutboxEvents' ٹیبل میں اسی لین دین کے اندر اسٹور کرنا شامل ہے جیسا کہ آپریشن خود ہوتا ہے۔ یہ نقطہ نظر متعلقہ ڈیٹا بیس کی ACID خصوصیات کے ساتھ اچھی طرح سے ہم آہنگ ہے۔ اس کے برعکس، بہت سے No-SQL ڈیٹا بیس مکمل طور پر ACID خصوصیات کی حمایت نہیں کرتے ہیں، اس کے بجائے CAP تھیوریم اور BASE فلسفہ کے اصولوں کا انتخاب کرتے ہیں، جو سخت مستقل مزاجی پر دستیابی اور حتمی مستقل مزاجی کو ترجیح دیتے ہیں۔ ٹرانزیکشنل آؤٹ باکس ٹرانزیکشنل آؤٹ باکس فراہم کرتا ہے اور اسے کئی طریقوں سے لاگو کیا جا سکتا ہے: کم از کم ایک بار گارنٹی ٹرانزیکشن لاگ ٹیلنگ پولنگ پبلشر اپروچ کا مطلب ڈیٹا بیس کے مخصوص حل جیسے CDC (Change Data Capture) کا استعمال کرنا ہے۔ اس نقطہ نظر کی اہم خرابیاں یہ ہیں: ٹرانزیکشن لاگ ٹیلنگ ڈیٹا بیس کے مخصوص حل CDC کے نفاذ کی تفصیلات کی وجہ سے تاخیر میں اضافہ دوسرا طریقہ ہے، جو آؤٹ باکس ٹیبل پر پولنگ کرکے آؤٹ باکس آف لوڈنگ کی سہولت فراہم کرتا ہے۔ اس نقطہ نظر کی بنیادی خرابی ڈیٹا بیس کے بوجھ میں اضافے کی صلاحیت ہے، جو زیادہ اخراجات کا باعث بن سکتی ہے۔ مزید برآں، تمام No-SQL ڈیٹا بیس مخصوص دستاویز کے حصوں کے لیے موثر استفسار کی حمایت نہیں کرتے ہیں۔ لہذا، پوری دستاویزات کو نکالنے کے نتیجے میں کارکردگی میں کمی واقع ہو سکتی ہے۔ پولنگ پبلشر یہاں ایک چھوٹی سی ترتیب کا خاکہ ہے جس میں بتایا گیا ہے کہ یہ کیسے کام کرتا ہے۔ خود ہی سنیں۔ ٹرانزیکشنل آؤٹ باکس پیٹرن کے ساتھ بنیادی چیلنج ڈیٹا بیس ACID خصوصیات پر انحصار میں ہے۔ یہ عام OLTP ڈیٹا بیس میں سیدھا ہو سکتا ہے لیکن NoSQL دائرے میں چیلنجز پیش کرتا ہے۔ اس سے نمٹنے کے لیے، ایک ممکنہ حل یہ ہے کہ درخواست کی کارروائی شروع کرنے سے ہی اپینڈ لاگ (مثال کے طور پر، کافکا) کا فائدہ اٹھایا جائے۔ 'لون کی درخواست جمع کروائیں' کمانڈ پر براہ راست کارروائی کرنے کے بجائے، ہم اسے فوری طور پر اندرونی کافکا موضوع پر بھیج دیتے ہیں اور پھر کلائنٹ کو 'قبول شدہ' نتیجہ واپس کر دیتے ہیں۔ تاہم، چونکہ یہ بہت زیادہ امکان ہے کہ کمانڈ پر ابھی بھی کارروائی کی ضرورت ہے، اس لیے ہم فوری طور پر صارف کو نتیجہ سے آگاہ نہیں کر سکتے۔ اس حتمی مستقل مزاجی کو منظم کرنے کے لیے، ہم تکنیکوں کو استعمال کر سکتے ہیں جیسے کہ طویل پولنگ، کلائنٹ کی طرف سے شروع کی گئی پولنگ، پرامید UI اپ ڈیٹس، یا اطلاعات کے لیے WebSockets یا سرور سے بھیجے گئے ایونٹس کا استعمال۔ تاہم، یہ مکمل طور پر ایک الگ موضوع ہے، تو آئیے اپنے ابتدائی موضوع کی طرف لوٹتے ہیں۔ ہم نے کافکا کے اندرونی موضوع پر پیغام بھیجا تھا۔ لون ایپلیکیشن سروس پھر اس پیغام کو استعمال کرتی ہے — وہی کمانڈ جسے اسے کلائنٹ سے موصول ہوا تھا — اور کارروائی شروع کر دیتی ہے۔ سب سے پہلے، یہ کچھ کاروباری منطق کو انجام دیتا ہے؛ صرف اس منطق کے کامیابی کے ساتھ عمل میں آنے اور نتائج برقرار رہنے کے بعد، یہ عوامی کافکا کے موضوع پر نئے پیغامات شائع کرتا ہے۔ آئیے تھوڑا سا سیوڈو کوڈ پر ایک نظر ڈالتے ہیں۔ public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } پریشان ہونے کی کوئی بات نہیں، چونکہ ابھی تک آفسیٹ کا ارتکاب نہیں ہوا ہے، اس لیے پیغام کی دوبارہ کوشش کی جائے گی۔ اگر کاروباری منطق کی پروسیسنگ ناکام ہو جائے تو کیا ہوگا؟ پریشان ہونے کی کوئی بات نہیں، چونکہ کاروبار کی منطق غیرمعمولی ہے، اس لیے یہ ڈپلیکیٹ قرض کی درخواست نہیں بنائے گی۔ اس کے بجائے، یہ عوامی کافکا کے موضوع پر پیغامات دوبارہ بھیجنے کی کوشش کرے گا۔ اگر کافکا کو نئے واقعات بھیجنا ناکام ہو جائے تو کیا ہوگا؟ پریشان ہونے کی کوئی بات نہیں، چونکہ کاروبار کی منطق غیرمعمولی ہے، اس لیے یہ قرض کی نقل کی درخواست نہیں بنائے گی۔ اس کے بجائے، یہ عوامی کافکا کے موضوع کو دوبارہ پیغامات بھیجے گا اور امید کرتا ہے کہ آفسیٹ کمٹ اس بار کامیاب ہو جائے گا۔ کیا ہوگا اگر پیغامات کافکا کو بھیجے جائیں، لیکن آفسیٹ کمٹ ناکام ہو جائے؟ اس نقطہ نظر کی اہم خرابیوں میں ایک نئے پروگرامنگ اسٹائل کے ساتھ منسلک اضافی پیچیدگی، حتمی مستقل مزاجی (چونکہ کلائنٹ کو فوری طور پر نتیجہ معلوم نہیں ہوگا) اور تمام کاروباری منطق کے بے ضمیر ہونے کی ضرورت شامل ہے۔ ایونٹ سورسنگ ایونٹ سورسنگ کیا ہے، اور اسے یہاں کیسے لاگو کیا جا سکتا ہے؟ ایونٹ سورسنگ ایک سافٹ ویئر آرکیٹیکچرل پیٹرن ہے جو کسی سسٹم کی حالت کو ماڈل بنانے کے لیے استعمال کیا جاتا ہے تاکہ اس کے ڈیٹا میں ہونے والی تمام تبدیلیوں کو ناقابل تغیر واقعات کی ایک سیریز کے طور پر حاصل کیا جا سکے۔ یہ واقعات حقائق یا ریاستی تبدیلیوں کی نمائندگی کرتے ہیں اور نظام کی موجودہ حالت کے لیے سچائی کے واحد ذریعہ کے طور پر کام کرتے ہیں۔ لہذا، تکنیکی طور پر، ایک ایونٹ سورسنگ سسٹم کو لاگو کرکے، ہمارے پاس پہلے سے ہی ایونٹ اسٹور میں تمام ایونٹس موجود ہیں، اور اس ایونٹ اسٹور کو صارفین اس کے بارے میں سچائی کے واحد ذریعہ کے طور پر استعمال کرسکتے ہیں۔ آرڈر کرنے کے بارے میں تمام تبدیلیوں یا خدشات کو ٹریک کرنے کے لیے کسی مخصوص ڈیٹا بیس کے حل کی ضرورت نہیں ہے، صرف ایک مسئلہ پڑھنے کی طرف بیٹھا ہے کیونکہ ہستی کی اصل حالت حاصل کرنے کے لیے تمام واقعات کو دوبارہ چلانے کی ضرورت ہوتی ہے۔ نتیجہ اس مضمون میں، ہم نے تقسیم شدہ نظاموں میں قابل اعتماد پیغام رسانی کی تعمیر کے لیے کئی طریقوں کا جائزہ لیا۔ ان خصوصیات کے ساتھ نظام بناتے وقت ہم کئی سفارشات پر غور کر سکتے ہیں۔ ہمیشہ کمزور صارفین تیار کریں کیونکہ نیٹ ورک کی ناکامی ناگزیر ہے۔ گارنٹی کے تقاضوں کی واضح تفہیم کے ساتھ احتیاط سے استعمال کریں۔ فرسٹ-لوکل-کمیٹ-پھر-پبلش کو اپروچ کا استعمال نہ کریں کیونکہ یہ آپ کے سسٹم میں ڈیٹا میں شدید تضاد کا باعث بن سکتا ہے۔ پہلے پبلش پھر لوکل کمٹ اگر موجودہ ڈیٹا بیس کے انتخاب کے فیصلے میں بہت زیادہ تبدیلی آسکتی ہے یا تکنیکی حکمت عملی کا مطلب مسئلہ کے لیے اسٹوریج کے بہترین حل کو منتخب کرنا ہے تو — جیسے ڈیٹا بیس کے حل کا پابند ہو کر مشترکہ لائبریریاں نہ بنائیں۔ CDC کم از کم ایک بار ضمانت کے حصول کے لیے ایک معیاری حل کے طور پر اپروچ کا استعمال کریں۔ ٹرانزیکشنل آؤٹ باکس جب No-SQL ڈیٹا بیس کا فائدہ اٹھایا جاتا ہے تو طریقہ کار کو استعمال کرنے پر غور کریں۔ خود کو سننے کے اگلی بار، ہم ٹرانزیکشنل آؤٹ باکس کو لاگو کرنے کی ایک زیادہ عملی مثال دیکھیں گے۔ دیکھیں تم!