Caching (ক্যাশিং ডিপ-ডাইভ)
ক্যাশিং হলো সিস্টেমের পারফরম্যান্স বাড়ানোর অন্যতম প্রধান হাতিয়ার। এটি মূলত স্লো স্টোরেজ (Disk/DB) থেকে ডেটা নিয়ে ফাস্ট মেমরিতে (RAM) সাময়িকভাবে জমা রাখে।
১. ক্যাশিং কী? (What is Caching?)
সহজ কথায়, ক্যাশিং হলো ডেটার একটি কপি কাছে রাখা যাতে পরের বার সেটি খুঁজতে অনেক সময় না লাগে। এটি ল্যাটেন্সি (Latency) কমায় এবং সিস্টেমের থ্রুপুট (Throughput) বাড়ায়।
২. রিড এবং রাইট পলিসি (Read/Write Policies)
ইন্টারভিউতে ক্যাশিং স্ট্যাটেজি সম্পর্কে প্রায়ই জিজ্ঞাসা করা হয়:
ক. Read-Through Cache
ইউজার যখন ডেটা খোঁজে, অ্যাপ প্রথমে ক্যাশে চেক করে। ক্যাশে না থাকলে (Cache Miss), ক্যাশ নিজেই ডাটাবেস থেকে ডেটা এনে নিজেকে আপডেট করে এবং ইউজারকে দেয়।
খ. Write-Through Cache
যেকোনো ডেটা রাইট করার সময় তা একই সাথে ক্যাশ এবং ডাটাবেস—উভয় জায়গায় লেখা হয়। এতে ডেটা কনসিস্টেন্সি খুব ভালো থাকে।
গ. Write-Around Cache
ডেটা শুধুমাত্র ডাটাবেসে লেখা হয়, ক্যাশে লেখা হয় না। রিমোট রিড রিকোয়েস্ট আসলে তখন ক্যাশে ডেটা ইম্পোর্ট করা হয়। এটি রাইট-হেভি সিস্টেমের জন্য ভালো।
ঘ. Write-Back (Write-Behind)
ডেটা প্রথমে শুধু ক্যাশে লেখা হয় এবং একটি নির্দিষ্ট সময় পর পর ব্যাকগ্রাউন্ডে ডাটাবেস আপডেট করা হয়। এটি অত্যন্ত ফাস্ট কিন্তু পাওয়ার কাট হলে ডেটা হারানোর রিস্ক থাকে।
৩. ক্যাশ ইভিকশন পলিসি (Cache Eviction Policies)
ক্যাশ মেমরি লিমিটেড থাকে, তাই নতুন ডেটা রাখতে হলে পুরনো ডেটা মুছতে হয়। এর জন্য কিছু নিয়ম আছে:
- LRU (Least Recently Used): যে ডেটাটি সবচেয়ে দীর্ঘ সময় ধরে ব্যবহৃত হয়নি, সেটি মুছে ফেলা হয়। (সবচেয়ে জনপ্রিয়)।
- LFU (Least Frequently Used): যে ডেটাটি সবচেয়ে কম সংখ্যক বার ব্যবহৃত হয়েছে সেটিকে মুছে ফেলা হয়।
- FIFO (First In First Out): যে ডেটা সবার আগে ক্যাশে ঢুকেছে সেটিকে আগে মোছা হয়।
৪. ডিস্ট্রিবিউটেড ক্যাশিং (Distributed Caching)
যখন অ্যাপ্লিকেশন স্কেল করা হয় এবং একাধিক সার্ভার থাকে, তখন একটি কমন মেমরি সার্ভার প্রয়োজন হয়। একেই ডিস্ট্রিবিউটেড ক্যাশিং বলে।
- টুলস: Redis, Memcached.
৫. কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN)
CDN হলো জিওগ্রাফিক্যালি ডিস্ট্রিবিউটেড এজ সার্ভার (Edge Servers) এর একটি নেটওয়ার্ক।
- ইউজার আপনার ওয়েবসাইট ভিজিট করলে তার সবচেয়ে কাছের সার্ভার থেকে ইমেজ, ভিডিও বা স্ট্যাটিক ফাইলগুলো সার্ভ করা হয়।
- এটি গ্লোবাল ল্যাটেন্সি অনেক কমিয়ে দেয়।
৬. সিনারিও ভিত্তিক প্রশ্ন (Scenario-based Questions)
সিনারিও ১: "আপনার সিস্টেমে Cache Hit Rate অনেক কম। আপনি কীভাবে এটি বাড়াবেন?"
সমাধান: ১. ক্যাশ অবজেক্টের TTL (Time to Live) চেক করব। সম্ভবত TTL খুব কম, তাই ডেটা বারবার ক্যাশ থেকে মুছে যাচ্ছে। ২. ক্যাশ ইভিকশন পলিসি পরিবর্তন করে দেখব (উদা: FIFO থেকে LRU)। ৩. বেশি ব্যবহৃত কুয়েরিগুলো প্রি-ক্যাশ (Pre-cache) করার ব্যবস্থা করব।
সিনারিও ২: "ক্যাশ স্ট্যাম্পিড (Cache Stampede) কী এবং এটি কীভাবে ঠেকাবেন?"
সমাধান: যখন কোনো হট কি (Hot Key) ক্যাশ থেকে এক্সপায়ার হয়ে যায় এবং হাজার হাজার রিকোয়েস্ট একসাথে ডাটাবেসে হিট করে, তখন একে ক্যাশ স্ট্যাম্পিড বলে। প্রতিরোধ: ১. লকিং ব্যবহার করা (যাতে মাত্র একজন ডিবি থেকে ডেটা আনতে পারে)। ২. প্রবালিকস্টিক রিফ্রেশ স্ট্যাটেজি ব্যবহার করা।
৭. গুরুত্বপূর্ণ ক্যাশ সমস্যা ও সমাধান (Critical Cache Issues)
সিস্টেম ডিজাইনে ক্যাশিং ব্যবহারের সময় ৩টি কমন সমস্যার ইন্টারভিউতে খুব বেশি জিজ্ঞাসা করা হয়:
ক. ক্যাশ পেনিট্রেশনের (Cache Penetration)
সমস্যা: যখন ইউজার এমন কিছু ডেটার জন্য রিকোয়েস্ট করে যা ক্যাশ এবং ডাটাবেস—কোথাও নেই। এতে প্রতিবার রিকোয়েস্ট ডাটাবেসে যায় এবং সিস্টেমের ওপর চাপ বাড়ে। সমাধান: ১. Bloom Filters: ডেটাবেসে যাওয়ার আগে দেখে নেওয়া যে ডেটাটি থাকার সম্ভাবনা আছে কি না। ২. Cache Empty Results: ডাটাবেসে ডেটা না থাকলেও ক্যাশে 'Null' ভ্যালু স্টোর করে রাখা (সামান্য সময়ের জন্য)।
খ. ক্যাশ এভল্যাঞ্চ (Cache Avalanche)
সমস্যা: যখন একসাথে অনেকগুলো ক্যাশ কি (Keys) এক্সপায়ার হয়ে যায় এবং সব রিকোয়েস্ট হঠাৎ করে ডাটাবেসে চলে যায়। সমাধান: ১. Random TTL: সব কি-তে একই সময় না দিয়ে ভিন্ন ভিন্ন র্যান্ডম সময় (TTL) দেওয়া। ২. Circuit Breaker: ডাটাবেস ওভারলোড হলে কিছু রিকোয়েস্ট রিজেক্ট করা।
গ. ক্যাশ ব্রেকডাউন (Cache Breakdown)
সমস্যা: একটি অত্যন্ত 'Hot Key' এক্সপায়ার হওয়ার কারণে হাজার হাজার রিকোয়েস্ট একসাথে ডাটাবেসে হিট করা। (এটি অনেকটা ক্যাশ স্ট্যাম্পিডের মতো)। সমাধান: Mutex Lock ব্যবহার করা যাতে মাত্র একটি কি রিফ্রেশ করার দায়িত্ব পায়।
৮. অ্যাডভান্সড সিনারিও ভিত্তিক প্রশ্ন (Advanced Scenario Questions)
সিনারিও ১: "Redis এবং Memcached এর মধ্যে আপনি কোনটি কখন বেছে নেবেন?"
সমাধান: ১. Redis: যখন ডেটা স্ট্রাকচার (Lists, Sets, Sorted Sets), ডেটা পারসিস্টেন্স (Persistence), বা Pub/Sub ফিচার প্রয়োজন হবে। ২. Memcached: যখন আপনার শুধু সিম্পল কি-ভ্যালু স্টোর এবং অত্যন্ত হাই পারফরম্যান্স রিড প্রয়োজন এবং ডেটা পারসিস্টেন্স দরকার নেই।
সিনারিও ২: "মাল্টি-লেভেল ক্যাশিং (Multi-level Caching) বলতে কী বোঝেন?"
সমাধান: সিস্টেমে অনেক সময় একটার বেশি ক্যাশ লেভেল থাকে। ১. L1 (Local Cache): অ্যাপ্লিকেশন সার্ভারের নিজস্ব মেমরিতে (উদা: Guava Cache)। এটি দ্রুততম। ২. L2 (Global Cache): ডিস্ট্রিবিউটেড ক্যাশ যেমন Redis। এটি সব সার্ভারের জন্য কমন। সুবিধা: L1 ক্যাশ নেটওয়ার্ক কল কমায়, আর L2 ক্যাশ ডেটা কনসিস্টেন্সি বজায় রাখে।
সিনারিও ৩: "একটি সোশ্যাল মিডিয়া অ্যাপের 'Trending Feed' এর জন্য আপনি কোন পলিসি ব্যবহার করবেন?"
সমাধান: ট্রেন্ডিং ফিডের জন্য আমরা Write-Back পলিসি ব্যবহার করতে পারি। যেহেতু এখানে প্রতি সেকেন্ডে মিলিয়ন রিকোয়েস্ট আসতে পারে, তাই প্রথমে ক্যাশে আপডেট করে পরে ডাটাবেসে সিঙ্ক করা পারফরম্যান্সের জন্য ভালো হবে।
CAUTION
ক্যাশিং ব্যবহার করার সময় Data Inconsistency বড় সমস্যা হয়ে দাঁড়াতে পারে। তাই ডাটাবেসের ডেটা চেঞ্জ হলে ক্যাশকে ইনভেলিডেট (Invalidate) করার সঠিক মেকানিজম থাকা জরুরি।