ریپلیکیشن سے مراد ایک ہی ڈیٹا کی کاپیاں ایک سے زیادہ مشینوں پر محفوظ کرنا ہے، تاکہ اگر ایک مشین ناکارہ ہو جائے تو بھی سروس کام کرتی رہے اور یہ نظام ایک مشین کی صلاحیت سے زیادہ ٹریفک (traffic) کو سنبھال سکے۔
اس تصور کو عملی مثال سے سمجھنے کے لیے، ہم ایک سادہ ‘یوزر پروفائل سروس’ کا استعمال کریں گے جو صارف کے نام، تصویر کے یو آر ایل (URL) اور ترتیبات (settings) کو پڑھنے اور اپ ڈیٹ کرنے کے لیے GET /profile/{user_id} اور PUT /profile/{user_id} کی سہولت فراہم کرتی ہے۔
ایک سرور تب تک کافی رہتا ہے جب تک کہ پروفائل ڈیٹا بیس ‘ناکامی کا واحد نقطہ’ (single point of failure) اور ‘تھرو پٹ کی واحد حد’ (single throughput ceiling) نہ بن جائے؛ کیونکہ ڈیٹا کو پڑھنے اور لکھنے (read and write) کا ہر عمل اسی ایک مشین کے درست اور تیز رفتار کام کرنے پر منحصر ہوتا ہے۔
اگلا مرحلہ ہماری ‘بیس لائن’ (معیاری سطح) کا تعین کرتا ہے تاکہ بعد کے اسباق میں اس نظام پر دباؤ ڈال کر یہ دیکھا جا سکے کہ یہ کن حالات میں ناکام ہوتا ہے۔
اس بنیادی ماڈل (baseline) میں، کلائنٹس API سروس کو کال کرتے ہیں اور API سروس ایک ہی ڈیٹا بیس سے ڈیٹا پڑھتی اور اس میں لکھتی ہے؛ چنانچہ ڈیٹا بیس کے کریش ہونے کی صورت میں پڑھنے اور لکھنے (reads and writes) دونوں عمل رک جاتے ہیں، اور ٹریفک میں اچانک اضافے (spike) کا بوجھ ایک ہی CPU اور ایک ہی ڈسک پر پڑتا ہے۔
یہی وہ پہلو ہے جو انٹرویوز میں ‘ریپلیکیشن’ (replication) کو ڈیزائن سے متعلق ایک اہم موضوع بناتا ہے، کیونکہ انٹرویو لینے والا اس بات پر زور دیتا ہے کہ خرابی (failure) یا زیادہ بوجھ (load) کی صورت میں کیا ہوگا، نہ کہ اس بات پر کہ کوئی ‘اینڈ پوائنٹ’ (endpoint) تکنیکی طور پر کیسے نافذ (implement) کیا گیا ہے۔
ریپلیکیشن کوئی ایک مخصوص فیچر نہیں ہے۔ یہ ایسے انتخاب کا مجموعہ ہے جن کا انحصار اس بات پر ہوتا ہے کہ سسٹم کے پرزوں (components) کے ناکارہ ہونے کی صورت میں سسٹم کو کن چیزوں کی ضمانت دینی ہے۔
مثال کے طور پر، ‘پروفائل سروس’ کے معاملے میں، انٹرویو لینے والا اکثر اس بات کی جانچ سے شروعات کرتا ہے کہ آیا ہم کسی مخصوص ٹیکنالوجی کا نام لینے سے پہلے ان چند تقاضوں کے بارے میں پوچھ سکتے ہیں جو ریپلیکیشن کے طریقہ کار (pattern) کو تبدیل کر دیتے ہیں۔
جن پہلوؤں یا ترتیبات (knobs) کی وضاحت درکار ہے، ان کا تعلق براہِ راست ‘ریڈ’ (read) اور ‘رائٹ’ (write) کے عمل سے ہے۔
ایک بار جب ان امور کی وضاحت ہو جائے، تو ریپلیکیشن (replication) محض ایک تجریدی تصور نہیں رہتی بلکہ ایک ٹھوس معاہدے کی شکل اختیار کر لیتی ہے؛ مثلاً یہ طے کرنا کہ آیا PUT /profile کی کامیابی کے فوراً بعد (چند سیکنڈز تک) GET /profile کے ذریعے پرانی تصویر کا دکھایا جانا قابلِ قبول ہے۔
ضروریات کے تعین کے بعد، ریپلیکیشن پر مبنی کم سے کم ڈیزائن میں ڈیٹا بیس کی صرف ایک اضافی کاپی شامل کی جاتی ہے اور یہ طے کیا جاتا ہے کہ اپ ڈیٹس (updates) ان کے درمیان کس طرح منتقل ہوں گی۔
فی الحال ہم ایپلیکیشن کے بنیادی طریقہ کار (semantics) کو تبدیل نہیں کرتے۔ کلائنٹس بدستور ایک ہی API ٹئیر (tier) سے رابطہ کرتے ہیں، اور API ٹئیر ایک ہی ‘لوجیکل رائٹ’ (logical write) جاری کرتا ہے؛ اس عمل کے دوران ڈیٹا کو خاموشی سے متضاد ورژنز (conflicting versions) میں تقسیم نہیں ہونا چاہیے۔