आप क्या cache करना है यह कैसे तय करते हैं, और invalidation कैसे संभालते हैं?

वह डेटा cache कीजिए जो बदलने से कहीं ज्यादा बार पढ़ा जाता है और जिसे बनाना महंगा है। invalidation के लिए, जो चीज थोड़ी पुरानी चल सकती है उस पर छोटा time to live रखिए, और जो नहीं चल सकती उस पर write के वक्त साफ साफ invalidation कीजिए। cache की key में वह सब कुछ डालिए जिससे नतीजा बदलता है, tenant और permissions समेत, और cache को हटाने लायक चीज मानिए: cache खाली होने पर भी सिस्टम सही चलना चाहिए।

मैं तीन गुण देखता हूं: लिखे जाने से कहीं ज्यादा पढ़ा जाना, बनाने में महंगा होना, और थोड़ा पुराना होने पर भी चल जाना। अगर आखिरी शर्त पूरी नहीं होती, जैसे account balance में, तो मैं उसे धीमा और सही रखना पसंद करूंगा। invalidation में मेरा डिफॉल्ट छोटा time to live है, क्योंकि वह खुद अपना इलाज कर लेता है; अगर किसी बग की वजह से मुझसे एक invalidation छूट जाए, तो समस्या हमेशा के लिए टिकने के बजाय साठ सेकंड में साफ हो जाती है। जहां पुरानापन सच में मंजूर नहीं है, वहां मैं write वाले उसी code path में invalidate करता हूं और अतिरिक्त coupling स्वीकार कर लेता हूं। जिस चीज पर मैं सबसे ज्यादा सावधान रहता हूं वह key है। जिससे भी नतीजा बदलता है वह उसमें जाता है, खासकर tenant या user id, क्योंकि caching का सबसे बुरा बग जो मैंने देखा है वह यह था कि CDN पर ऐसा response cache हो गया जिसमें personalized header था, और एक कस्टमर को कुछ देर दूसरे कस्टमर का नाम दिख गया। और मैं हमेशा cache खाली करके टेस्ट करता हूं, क्योंकि अगर सिस्टम ठंडे cache पर गिर जाता है, तो वह cache नहीं, dependency है।