कभी एक्सपायर न होने वाली API कुंजियों की समस्या
कई साल पहले जारी की गई कुंजी, जिसे कभी रोटेट नहीं किया गया और जो आज भी मान्य है, कोई सुविधा नहीं है। यह एक जोखिम है जिसे सालों से किसी ने वास्तव में देखा तक नहीं।
"रियल-टाइम" लोकेशन डेटा के लिए वास्तव में क्या चाहिए
"रियल-टाइम" कई लोकेशन डेटा प्रोडक्ट के साथ तेज़ रिस्पॉन्स समय के संक्षिप्त रूप के रूप में जोड़ा जाता है, और गति वास्तव में एक असली और सार्थक चीज़ है जिसके लिए ऑप्टिमाइज़ किया जाए। लेकिन यह उस दावे से बिल्कुल अलग दावा है जो दुनिया की वर्तमान स्थिति के बारे में कुछ बताने वाले डेटा के लिए "रियल टाइम" का वास्तव में मतलब होना चाहिए: कि जवाब वह दर्शाता है जो अभी सच है, न कि किसी ऐसे डेटासेट पर तेज़, कम लेटेंसी वाला लुकअप जो खुद कुछ समय पहले संकलित हुआ था और तब से उसमें कोई सार्थक अपडेट नहीं हुआ।
यह फ़र्क खास तौर पर IP जियोलोकेशन के लिए सबसे ज़्यादा मायने रखता है, क्योंकि IP पता श्रेणियों और उनके भौतिक स्थान के बीच का संबंध समय के साथ बदलता है, जब उन्हें प्रबंधित करने वाली क्षेत्रीय इंटरनेट रजिस्ट्रियाँ पता ब्लॉक को दोबारा सौंपती हैं, दोबारा आवंटित करती हैं या किसी दूसरे काम में लगाती हैं। जो लुकअप पुराने संबंध के आधार पर कुछ मिलीसेकंड में जवाब देता है, वह एक ही समय में तेज़ भी है और गलत भी, और गति उस गलती को ठीक करने के लिए कुछ नहीं करती। असली रियल टाइम IP जियोलोकेशन के लिए ज़रूरी है कि मूल संबंध खुद अद्यतन रखा जाए, एक लाइव लुकअप प्रक्रिया और एक ऐसे कैश के साथ जो तय, एक बार के स्नैपशॉट की तरह माने जाने के बजाय रिफ़्रेश होता रहे।
हमने अपना IP जियोलोकेशन खास तौर पर इसी फ़र्क के इर्द-गिर्द बनाया है: यह लाइव चलता है, कैशिंग का इस्तेमाल रिस्पॉन्स समय कम रखने के लिए होता है, ताज़गी के विकल्प के रूप में नहीं, और एक बैकग्राउंड रीट्राई प्रक्रिया है जो दोबारा जाँच की ज़रूरत वाले डेटा पर काम करती रहती है, बजाय इसके कि कोई समय-समय पर चलने वाला cron job संबंध को अद्यतन रखने का एकमात्र तरीका हो। लक्ष्य यह है कि कैश इसे तेज़ बनाए, पुराना नहीं, जो उस कैश से अलग डिज़ाइन लक्ष्य है जो केवल इसलिए मौजूद है ताकि कभी कुछ दोबारा गणना न करना पड़े, चाहे वह अद्यतन हो या नहीं।
यही फ़र्क, एक अलग रूप में, समय क्षेत्र डेटा पर भी लागू होता है। ऐसे ऑफ़सेट का वर्णन करने वाला तेज़ रिस्पॉन्स जिसमें हाल के डेलाइट सेविंग बदलाव या हाल के किसी सरकारी नियम बदलाव को शामिल नहीं किया गया, किसी भी सार्थक अर्थ में रियल टाइम नहीं है, भले ही वह दस मिलीसेकंड में लौटा हो। यहाँ रियल टाइम का मतलब है कि मूल संदर्भ, इस मामले में IANA समय क्षेत्र डेटाबेस, बदलने के साथ-साथ ट्रैक और लागू किया जा रहा है, न कि यह कि रिस्पॉन्स किसी ऐसी तालिका से जल्दी आ गया जिसे हाल में किसी ने छुआ नहीं।
हमें लगता है कि "रियल टाइम" को पहले डेटा के अद्यतन होने के दावे के रूप में और दूसरे नंबर पर रिस्पॉन्स लेटेंसी के दावे के रूप में माना जाना चाहिए, भले ही लेटेंसी वह हिस्सा है जिसे मापना और दिखाना सबसे आसान है। कोई प्रदाता वास्तव में रिस्पॉन्स समय को एक सेकंड के छोटे हिस्से तक ऑप्टिमाइज़ कर सकता है और साथ ही चुपचाप मूल डेटा को महीनों तक पुराना होने दे सकता है, और बाहर से एक तेज़ गलत जवाब और एक तेज़ सही जवाब तब तक एक जैसे दिखते हैं जब तक आगे कोई चीज़ उस फ़र्क पर निर्भर न हो। ज़्यादा कठिन, कम दिखने वाला काम खुद डेटा को अद्यतन रखना है। यही वह हिस्सा है जो वास्तव में इस लेबल का हकदार बनाता है, और यही वह हिस्सा भी है जिसे ग्राहक केवल किसी अनुरोध का समय मापकर सत्यापित नहीं कर सकता।