रेप्लिकेशन का मतलब है एक ही डेटा की कॉपी कई मशीनों पर रखना, ताकि अगर एक मशीन खराब हो जाए तो भी सर्विस चलती रहे और यह एक मशीन की क्षमता से ज़्यादा ट्रैफ़िक संभाल सके।
इसे बेहतर ढंग से समझने के लिए, हम एक आसान यूज़र प्रोफ़ाइल सर्विस का इस्तेमाल करेंगे जो यूज़र का नाम, फ़ोटो URL और सेटिंग्स पढ़ने और अपडेट करने के लिए GET /profile/{user_id} और PUT /profile/{user_id} को सपोर्ट करती है।
एक सर्वर तब तक काफ़ी है जब तक प्रोफ़ाइल डेटाबेस ‘सिंगल पॉइंट ऑफ़ फ़ेलियर’ (यानी जिसके खराब होने पर पूरी सर्विस रुक जाए) और ‘सिंगल थ्रूपुट सीलिंग’ (यानी काम करने की अधिकतम सीमा) न बन जाए, क्योंकि हर ‘रीड’ और ‘राइट’ ऑपरेशन उसी एक मशीन के सही और तेज़ चलने पर निर्भर करता है।
अगला हिस्सा हमारी बेसलाइन तय करता है ताकि बाद के लेसन में हम उस पर दबाव डालकर देख सकें कि वह कहाँ जाकर फेल होती है।
उस बेसलाइन में, क्लाइंट API सर्विस को कॉल करते हैं और API सर्विस एक ही डेटाबेस से डेटा पढ़ती और लिखती है। इसलिए, अगर डेटाबेस क्रैश हो जाता है, तो डेटा पढ़ने और लिखने दोनों काम रुक जाते हैं और ट्रैफ़िक बढ़ने पर एक ही CPU और डिस्क पर बहुत ज़्यादा लोड आ जाता है।
इसी वजह से इंटरव्यू में रेप्लिकेशन एक ज़रूरी डिज़ाइन टॉपिक बन जाता है, क्योंकि इंटरव्यू लेने वाला यह नहीं देखता कि एंडपॉइंट को कैसे लागू किया गया है, बल्कि इस बात पर ज़ोर देता है कि फ़ेलियर (सिस्टम के खराब होने) और ज़्यादा लोड के समय क्या होता है।
रेप्लिकेशन कोई एक फ़ीचर नहीं है। यह कई विकल्पों का एक सेट है जो इस बात पर निर्भर करता है कि सिस्टम के कुछ हिस्सों के खराब होने पर सिस्टम क्या गारंटी देता है।
प्रोफ़ाइल सर्विस के मामले में, इंटरव्यू लेने वाला अक्सर यह जाँचकर शुरुआत करता है कि क्या हम उन कुछ ज़रूरतों के बारे में पूछ सकते हैं जो रेप्लिकेशन पैटर्न को बदलती हैं, और ऐसा वह किसी खास टेक्नोलॉजी का नाम लेने से पहले करता है।
साफ़ करने के लिए ज़रूरी पैरामीटर सीधे रीड और राइट फ़्लो से जुड़े होते हैं।
एक बार ये बातें तय हो जाने के बाद, रेप्लिकेशन सिर्फ़ एक अमूर्त विचार नहीं रह जाता, बल्कि एक ठोस कॉन्ट्रैक्ट बन जाता है; जैसे कि क्या PUT /profile के सफल होने के कुछ सेकंड बाद तक GET /profile पुरानी फ़ोटो दिखा सकता है।
ज़रूरतों को तय करने के बाद, सबसे छोटे रेप्लिकेटेड डिज़ाइन में ठीक एक और डेटाबेस कॉपी जोड़ी जाती है और यह तय किया जाता है कि उनके बीच अपडेट कैसे होंगे।
अभी के लिए हम एप्लिकेशन के काम करने के तरीके (सिमेंटिक्स) को नहीं बदलते हैं। क्लाइंट अभी भी एक API टियर से बात करते हैं, और API टियर अभी भी एक लॉजिकल राइट ऑपरेशन करता है, जो चुपचाप अलग-अलग और आपस में टकराने वाले वर्शन में नहीं बंटना चाहिए।