CAP theorem समझाइए और बताइए कि वह आपके काम किए हुए किसी सिस्टम पर कैसे लागू हुआ।

CAP कहता है कि जब network partition आपके nodes को बांट देता है, तो आपको consistency और availability में से एक चुनना पड़ता है। partition tolerance से आप बच नहीं सकते, क्योंकि नेटवर्क आपकी योजना की परवाह किए बिना फेल होते हैं। तो असली सवाल यह है कि partition के दौरान आपका सिस्टम क्या करता है: सही बने रहने के लिए writes मना कर देता है, या उन्हें ले लेता है और बाद में मिलान करता है। partition के बाहर आपको दोनों मिल सकते हैं, इसीलिए रोजमर्रा का सौदा असल में latency का है।

मैं इसे यूं रखता हूं कि partition tolerance कोई चुनाव नहीं है, क्योंकि packets गिरते हैं और switches फेल होते हैं, चाहे मेरा आर्किटेक्चर कुछ भी हो। तो CAP असल में यह पूछ रहा है कि बंटे हुए हालात में सिस्टम क्या करता है: write मना कर दे ताकि किसी को पुराना डेटा न मिले, या write ले ले और बाद में सुलझाए। PACELC वाले विस्तार में मुझे यह अच्छा लगता है कि वह उस हिस्से का नाम लेता है जिससे आप रोज जूझते हैं, यानी सब कुछ ठीक होने पर भी आप latency को consistency से तोल रहे होते हैं, क्योंकि regions के बीच quorum write में round trips की कीमत लगती है। जिस प्रोडक्ट पर मैंने काम किया, वहां हमने इसे फीचर के हिसाब से बांटा। billing को छूने वाली हर चीज primary से गुजरती थी और उसमें read after write की गारंटी थी, क्योंकि किसी से दो बार पैसे लेकर सिर्फ माफी से बात नहीं बनती। activity feed replicas से पढ़ती थी और कुछ सेकंड पीछे रह सकती थी, और किसी को कभी पता तक नहीं चला। एक ही सिस्टम, दो जवाब, फीचर के हिसाब से चुने गए, आर्किटेक्चर के धर्म की तरह नहीं।