يُقصد بالنسخ المتماثل الاحتفاظ بنسخ من البيانات نفسها على أكثر من جهاز؛ وذلك لضمان استمرار عمل الخدمة في حال تعطل أحد الأجهزة، ولتمكينها من التعامل مع حركة مرور بيانات تفوق قدرة جهاز واحد.
ولتوضيح ذلك عملياً، سنستخدم خدمة بسيطة لملفات تعريف المستخدمين تدعم العمليتين GET /profile/{user_id} و PUT /profile/{user_id} لقراءة وتحديث اسم المستخدم، ورابط الصورة، والإعدادات.
يكون الخادم الواحد كافياً إلى أن تصبح قاعدة بيانات ملفات التعريف “نقطة الفشل الوحيدة” و"العائق الوحيد أمام معدل المعالجة" (throughput ceiling)؛ إذ تعتمد كل عملية قراءة أو كتابة على سلامة ذلك الجهاز الواحد وسرعة أدائه.
يُرسّخ العرض التالي نقطة مرجعية أساسية لنظامنا، مما يتيح لنا في الدروس اللاحقة اختبار النظام تحت الضغط ومراقبة مواطن الانهيار فيه.
في هذا السيناريو الأساسي، تتواصل تطبيقات العملاء (Clients) مع خدمة واجهة برمجة التطبيقات (API)، وتقوم هذه الخدمة بعمليات القراءة والكتابة في قاعدة بيانات واحدة؛ لذا فإن تعطل قاعدة البيانات يؤدي إلى توقف كل من عمليات القراءة والكتابة، كما تتراكم أحمال حركة المرور (Traffic spike) لتضغط على وحدة معالجة مركزية (CPU) واحدة وقرص تخزين واحد.
هذا هو التحدي الذي يجعل من “النسخ المتماثل للبيانات” (Replication) موضوعاً جوهرياً في مقابلات التصميم؛ إذ سيركز المحاور على ما يحدث أثناء حالات الفشل وتحت وطأة الأحمال العالية، بدلاً من التركيز على كيفية تنفيذ نقطة نهاية (Endpoint) معينة.
النسخ المتماثل ليس مجرد ميزة واحدة، بل هو مجموعة من الخيارات التي تعتمد على ما يجب أن يضمنه النظام عند تعطل أجزاء منه.
في حالة “خدمة الملفات الشخصية” (Profile service)، عادةً ما يبدأ المحاور باختبار قدرتنا على تحديد المتطلبات القليلة التي تؤثر في نمط النسخ المتماثل، وذلك قبل التطرق إلى أي تقنية محددة.
ترتبط المعايير التي يجب توضيحها ارتباطاً مباشراً بمسارات عمليات القراءة والكتابة.
بمجرد تحديد هذه الجوانب، تتحول عملية النسخ المتماثل من مجرد فكرة مجردة إلى اتفاقية محددة وملموسة؛ على سبيل المثال، تحديد ما إذا كان يُسمح للطلب GET /profile بإرجاع صورة قديمة لبضع ثوانٍ بعد نجاح الطلب PUT /profile.
بعد تحديد المتطلبات، يتمثل أبسط تصميم للنسخ المتماثل في إضافة نسخة واحدة إضافية من قاعدة البيانات وتحديد آلية انتقال التحديثات بين النسختين.
نُبقي دلالات عمل التطبيق (application semantics) كما هي في الوقت الراهن؛ حيث تظل تطبيقات العملاء تتواصل مع طبقة واجهة برمجة تطبيقات (API tier) واحدة، وتستمر هذه الطبقة في إصدار عملية كتابة منطقية واحدة لا ينبغي أن تتفرع خفيةً إلى إصدارات متضاربة.