“बस इसे Redis में कैश कर दो” — आपने यह किसी कोड रिव्यू में, सिस्टम डिज़ाइन इंटरव्यू में, या Stack Overflow कमेंट में ज़रूर सुना होगा। यह अब लगभग एक रिफ्लेक्स बन चुका है। लेकिन Redis ही क्यों? एक अच्छे इंडेक्स वाले रेगुलर डेटाबेस से क्यों नहीं, या किसी और इन-मेमोरी स्टोर से? मैंने इसके इतिहास, आर्किटेक्चर, और विकल्पों के मौजूदा परिदृश्य में गहराई से देखा — और यह कहानी मीम से कहीं ज़्यादा दिलचस्प है।
अधिकांश डेवलपर सभी indexes को एक साथ मिला देते हैं — “बस कुछ जो queries को तेज़ बनाता है” — यह समझे बिना कि Elasticsearch और Oracle DB बिल्कुल अलग समस्याओं को हल कर रहे हैं। वे समान डेटा को मौलिक रूप से विपरीत तरीकों से index करते हैं, और यह अंतर उनके प्रदर्शन के बारे में सब कुछ निर्धारित करता है।
मुझे आपको दिखाने दीजिए कि Oracle पर पूर्ण-पाठ खोज कठिन क्यों लगती है, जबकि Elasticsearch इसे सरल बना देता है।
आप एक API एंडपॉइंट /api/orders/1042 एक्सपोज़ करते हैं। वह इंटीजर किसी को भी — एक प्रतिस्पर्धी, एक हमलावर, एक जिज्ञासु उपयोगकर्ता — बिल्कुल बता देता है कि आपके पास कितने ऑर्डर हैं। नंबर को 1041 में बदलें, तो पिछला ऑर्डर मिल जाता है। इसे 1 में बदलें, तो पहला ऑर्डर मिल जाता है। कोई auth bypass की ज़रूरत नहीं। ID खुद ही जानकारी का रिसाव है।
यही एक पैराग्राफ में अनुक्रमिक ID की समस्या है। UUID इसे ठीक करने के लिए मौजूद है — और कुछ अन्य चीज़ें जो स्केल पर मायने रखती हैं।