read heavy endpoint के आगे caching की परत कैसे जोड़ेंगे बिना बहुत बासी डेटा परोसे?

सबसे छोटा TTL चुनिए जो फिर भी फर्क डाले, फिर write पर invalidate कीजिए, यानी उसी रास्ते में key मिटाइए या बदलिए जो row बदलता है। key में हर वह input रखिए जो नतीजा बदलता है, tenant और schema का version भी। single flight locking जोड़िए ताकि एक miss डेटाबेस पर भगदड़ न मचाए। जहां बासीपन बेज़रर है वहां उसे साफ तौर पर स्वीकार कीजिए, और hit rate ट्रैक कीजिए ताकि पता रहे कि यह काम कर रहा है।

कुछ भी जोड़ने से पहले मैं देखता हूं कि query को ही तेज़ किया जा सकता है या नहीं, क्योंकि खराब query के आगे लगा cache समस्या तब तक छिपाता है जब तक सबसे बुरे वक्त पर miss न हो जाए। मान लीजिए यह सच में read heavy है, तो मैं Redis में cache aside चुनता हूं। key में tenant id, असली query parameters, और एक version prefix होता है जिसे मैं deploy पर बढ़ा सकता हूं ताकि बदली हुई response की शक्ल कभी पुरानी entries से न परोसी जाए। TTL मशीनरी नहीं, सुरक्षा जाल है: मैं write पर साफ तौर पर invalidate करता हूं, उसी कोड रास्ते में जो row अपडेट करता है, तो सामान्य हाल में बासीपन की खिड़की मिलीसेकंड की होती है। जिस नाकामी की मैं योजना बनाता हूं वह भगदड़ है, जहां कोई गर्म key expire होती है और दो सौ requests एक साथ miss होकर डेटाबेस पर जा गिरती हैं, तो मैं single flight lock लगाता हूं और बाकी को जीतने वाले का इंतज़ार करने देता हूं। फिर मैं hit rate को मेट्रिक की तरह निकालता हूं, क्योंकि जो cache किसी refactor के बाद 95 प्रतिशत से 10 पर गिर जाए, उसका पता डेटाबेस गिरने तक चलता ही नहीं।