एक डेवलपर ने क्लाइंट-साइड पोलिंग इंटरवल को 30 सेकंड से बढ़ाकर 15 मिनट करके Neon के सर्वरलेस-डेटाबेस कंप्यूट चार्जेस को कम कर दिया। लंबा अंतराल डेटाबेस को इतना समय देता है कि वह 'स्केल टू ज़ीरो' (scale to zero) हो सके, जिससे उन कंप्यूट क्रेडिट्स की बचत होती जो लगातार 30-सेकंड की पोलिंग के कारण खर्च हो रहे थे।
Neon अपने कंप्यूट इंजन के चलने के हर सेकंड के लिए बिल लेता है। एक सामान्य सर्वरलेस सेटअप में, कोई भी रिक्वेस्ट—चाहे वह कितनी भी छोटी क्यों न हो—इंजन को सक्रिय रखती है। लेखक का TV डैशबोर्ड हर आधे मिनट में डेटाबेस को क्वेरी करता था, भले ही प्रदर्शित डेटा केवल तभी बदलता था जब कोई उपयोगकर्ता मैन्युअल रूप से सिंक करता था या कोई नया प्रसारण शुरू होता था। इस पैटर्न के कारण Neon का कंप्यूट पूल कभी भी उस 'ज़ीरो-स्टेट' (zero-state) तक नहीं पहुँच पाता था जो बिलिंग को रोकता है, जिससे Vercel कॉस्ट डैशबोर्ड पर नियमित स्पाइक्स दिखाई देते थे।
मूल पोलिंग क्यों महत्वपूर्ण थी
- डैशबोर्ड पूरी तरह से क्लाइंट-साइड React कंपोनेंट था, इसलिए प्रत्येक ब्राउज़र इंस्टेंस सीधे Neon को हिट करता था।
- Neon की प्राइसिंग लागत को एक्टिव कंप्यूट टाइम से जोड़ती है, न कि रिक्वेस्ट काउंट से, इसलिए हर 30 सेकंड में एक हिट बेसलाइन चार्ज बनाए रखता था।
- लेखक के Vercel मॉनिटरिंग ने ट्रैफिक और Neon कंप्यूट उपयोग के बीच संबंध दिखाया, जिससे पुष्टि हुई कि पोलिंग डेटाबेस को सक्रिय रख रही थी।
विफल वर्कअराउंड
एक त्वरित डिबाउंस (debounce)—अंतिम उपयोगकर्ता इंटरैक्शन के बाद अनुरोध में देरी करना—काम नहीं आया क्योंकि टाइमर अभी भी हर 30 सेकंड में चल रहा था। मैंने Vercel Edge Functions का उपयोग करने की भी कोशिश की, लेकिन उससे जटिलता बहुत बढ़ गई।
सरल समाधान
आवश्यक एकमात्र कोड परिवर्तन रिफ्रेश इंटरवल को परिभाषित करने वाले एक कांस्टेंट (constant) को बदलना था:
- 30 सेकंड से → 5 मिनट
- फिर 5 मिनट से → 15 मिनट
15 मिनट पर, Neon के पास निष्क्रियता को पहचानने और अपने कंप्यूट संसाधनों को स्पिन डाउन (spin down) करने के लिए पर्याप्त समय होता है। डैशबोर्ड कार्यात्मक बना रहता है: उपयोगकर्ता जब मैन्युअल रूप से रिफ्रेश करते हैं तो उन्हें अभी भी नवीनतम डेटा दिखाई देता है, और कभी-कभार होने वाली ऑटोमैटिक पोलिंग बिना किसी निरंतर शोर के नए प्रसारण को पकड़ लेती है।
क्लाइंट-साइड पर पोलिंग क्यों रखें?
- सरलता – कोई अतिरिक्त सर्वरलेस फंक्शन या बिल्ड स्टेप्स नहीं।
- उपयोगकर्ता की अपेक्षाएं – डैशबोर्ड पहले से ही एक क्लाइंट ऐप की तरह व्यवहार करता है; मैन्युअल क्लिक से अभी भी तुरंत अपडेट मिलता है।
- कॉस्ट मॉडल के साथ तालमेल – Neon कंप्यूट के प्रति सेकंड के हिसाब से चार्ज करता है, न कि प्रति रिक्वेस्ट, इसलिए फ्रीक्वेंसी कम करने से बिल सीधे तौर पर कम हो जाता है।
सर्वरलेस डेवलपर्स के लिए सबक
- पोलिंग फ्रीक्वेंसी को अपने डेटा के वास्तविक अपडेट चक्र (cadence) के साथ मिलाएं। यदि कोई डेटासेट एक घंटे में केवल कुछ ही बार बदलता है, तो 15 मिनट का अंतराल अक्सर पर्याप्त होता है।
- सर्वरलेस वातावरण में बार-बार पोलिंग करना एक छिपा हुआ लागत कारक (cost driver) है; प्रति मिनट एक अतिरिक्त रिक्वेस्ट भी डेटाबेस को कभी स्केल डाउन होने से रोक सकती है।
- बिना किसी आर्किटेक्चरल ओवरहाल के, छोटे कॉन्फ़िगरेशन बदलाव बड़ी बचत कर सकते हैं।
निष्कर्ष: एक एकल कांस्टेंट बदलाव ने लगातार सक्रिय रहने वाले डेटाबेस को वास्तव में एक सर्वरलेस कंपोनेंट में बदल दिया, जिससे डैशबोर्ड की उपयोगिता बनाए रखते हुए कंप्यूट खर्च कम हो गया। Neon या इसी तरह की प्रति-सेकंड कंप्यूट सेवाओं का उपयोग करने वाली किसी भी टीम के लिए, पोल इंटरवल की समीक्षा करना एक त्वरित जीत है जिसे आज ही आज़माना चाहिए।