Caching কী? অ্যাপ বিল্ডারদের জন্য সহজ গাইড
Caching মানে কোনো ধীর বা ব্যয়বহুল জিনিসের একটি তৈরি কপি রাখা, যাতে সেটির পরের অনুরোধ সেই কপি থেকে দ্রুত দেওয়া যায়। সংরক্ষিত কপিটিকে বলা হয় cache। আপনার ব্রাউজার ছবি ক্যাশ করে, তাই দ্বিতীয়বার ভিজিটে সাইট দ্রুত লোড হয়; একটি সার্ভার ধীর ডেটাবেস কোয়েরির ফল ক্যাশ করে, যাতে প্রতিটি ভিজিটরের জন্য সেটি আবার চালাতে না হয়।
Caching অ্যাপকে দ্রুত ও চালাতে সস্তা করে। এর একটি বড় আপস হলো, কপিটি পুরোনো হয়ে যেতে পারে।
AI দিয়ে অ্যাপ বানালে caching কেন গুরুত্বপূর্ণ
AI-তৈরি অ্যাপে তিনভাবে caching-এর মুখোমুখি হবেন:
- “আমি অ্যাপ আপডেট করেছি, কিন্তু এখনও পুরোনো ভার্সন দেখছি।” এটি সবচেয়ে সাধারণ caching-এর মুহূর্ত, এবং সাধারণত ক্ষতিকর নয় — আপনার ব্রাউজার বা একটি CDN একটি সংরক্ষিত কপি দেখাচ্ছে।
- গতি। যদি কোনো পেজ ধীর হয় কারণ প্রতিটি ভিজিটরের জন্য একই হিসাব আবার করা হয়, ফলাফল ক্যাশ করলে সেটি তাৎক্ষণিক মনে হতে পারে।
- খরচ। অনেক AI বিল্ডার ও হোস্ট কম্পিউট, ডেটাবেস সময় ও বাইরের API কলের জন্য টাকা নেয়। হাজার ভিজিটর একই ব্যয়বহুল অনুরোধ করলে caching করে আপনি একবারই দাম দেন।
মূল বিষয়গুলো জানা থাকলে আপনি যেখানে সাহায্য করবে সেখানে caching চাইতে পারেন, এবং কিছু ভুল দেখালে সেটি caching-এর কারণ কি না তা চিনতে পারেন।
একটি দৈনন্দিন উপমা
একটি ব্যস্ত ক্যাফের রান্নাঘরের কথা ভাবুন।
প্রতি সকালে শেফ চাইলে অর্ডার আসার সাথে সাথে তাজা বিন পিষে প্রতিটি কফি বানাতে পারেন। কিন্তু সেটি ধীর। তার বদলে তিনি গরম প্লেটে ফিল্টার কফির একটি পট তৈরি রাখেন। বেশিরভাগ গ্রাহক কয়েক সেকেন্ডে এক কাপ পান — এটি একটি cache hit। পট শেষ হলে কেউ একটি নতুন পট বানায় — একটি cache miss।
কিন্তু বেশিক্ষণ রাখা কফি বাসি হয়ে যায়, তাই ক্যাফের একটি নিয়ম আছে: ৩০ মিনিটের পুরোনো যেকোনো পট ফেলে দিতে হবে। এই নিয়মটিই ক্যাশের মেয়াদ শেষের সময়। কেউ সারাদিন একই পট রাখবে না, আর কারও কাস্টম অর্ডার — ওটমিল্ক ও তিন চামচ চিনি — আগে থেকে বানিয়ে রাখা হবে না; কিছু জিনিস আদৌ ক্যাশ করা উচিত নয়।
ক্যাশ কোথায় থাকে
একটি পেজ লোড হতে একাধিক ক্যাশের মধ্য দিয়ে যেতে পারে, ব্যবহারকারীর কাছাকাছি থেকে দূরের দিকে:
| ক্যাশ | কোথায় থাকে | সাধারণত কী সংরক্ষণ করে | উদাহরণ |
|---|---|---|---|
| Browser cache | ভিজিটরের ডিভাইসে | ছবি, স্টাইলশিট, স্ক্রিপ্ট, ফন্ট | দ্বিতীয় পেজে আপনার লোগো তাৎক্ষণিক লোড হয় |
| CDN cache | পৃথিবীজুড়ে সার্ভার, ভিজিটরের কাছাকাছি | স্ট্যাটিক ফাইল এবং কখনও পুরো পেজ | টোকিওর একজন ভিজিটর আপনার মূল সার্ভার থেকে নয়, কাছের একটি সার্ভার থেকে ফাইল পায় |
| Application cache | আপনার সার্ভারে বা তার কাছে, প্রায়ই মেমরি বা Redis-এ | ধীর কোয়েরি বা বাইরের API কলের ফল | আজকের এক্সচেঞ্জ রেট, ঘণ্টায় একবার আনা |
| Database cache | ডেটাবেসের ভেতরে | সম্প্রতি ব্যবহৃত ডেটা ও কোয়েরি প্ল্যান | জনপ্রিয় সারিগুলো দ্রুত মেমরিতে থাকে |
CDN (content delivery network) মূলত আপনার সাইটের ফাইলের জন্য বিশ্বজুড়ে ক্যাশের একটি নেটওয়ার্ক।
ক্যাশ কীভাবে ঠিক করে কী রাখবে
প্রতিটি ক্যাশকে একই প্রশ্নের উত্তর দিতে হয়:
- কী ক্যাশ করা যায়? পাবলিক, শেয়ার করা ডেটা (একটি পণ্যের ছবি, একটি ব্লগ পোস্ট) — হ্যাঁ। ব্যক্তিগত ডেটা (একজন ব্যবহারকারীর অ্যাকাউন্ট পেজ, তার বার্তা) — শেয়ার করা ক্যাশে কখনও নয়।
- কতক্ষণের জন্য? এটিই TTL (time to live)। একটি লোগো এক বছরের জন্য ক্যাশ হতে পারে; একটি স্টক লেভেল ৩০ সেকেন্ডের জন্য।
- কীভাবে এটি হালনাগাদ হয়? হয় কপির মেয়াদ শেষ হয় ও আবার আনা হয়, নয়তো ডেটা বদলালে অ্যাপ ইচ্ছে করে সেটি সরিয়ে দেয় — একে বলে invalidation।
ওয়েবসাইটের জন্য সার্ভার Cache-Control হেডার ব্যবহার করে ব্রাউজার ও CDN-কে বলে প্রতিটি ফাইল কীভাবে ক্যাশ করতে হবে। যেমন Cache-Control: max-age=3600 মানে “এই কপিটি এক ঘণ্টা পুনরায় ব্যবহার করা যাবে।”
আধুনিক বিল্ড টুল স্ট্যাটিক ফাইলের কঠিনতম অংশটি cache busting দিয়ে সামলায়: ফাইল বদলালে প্রতিবার সেটি একটি ফিঙ্গারপ্রিন্টসহ নতুন নাম পায়, যেমন app.3f9a2c.js। ব্রাউজার পুরোনো নামটি দীর্ঘ সময় ক্যাশ করে রাখতে পারে, কারণ নতুন ভার্সনের নাম সম্পূর্ণ আলাদা।
একটি বাস্তব উদাহরণ: একটি পণ্য ক্যাটালগ
আপনার একটি ছোট অনলাইন দোকান আছে। হোম পেজে ডেটাবেস থেকে ৫০টি পণ্যের দাম ও স্টক লেভেল দেখায়, সঙ্গে একটি “ট্রেন্ডিং” তালিকা, যার জন্য সব অর্ডারের ওপর একটি ধীর হিসাব লাগে।
- ছবি ও স্ক্রিপ্ট ব্রাউজার ও CDN দীর্ঘ সময়ের জন্য ক্যাশ করে। প্রতিটি নতুন বিল্ড বদলানো ফাইলকে নতুন নাম দেয়, তাই আপডেট তবুও দেখা যায়।
- ট্রেন্ডিং তালিকা প্রতি ১০ মিনিটে একবার হিসাব হয় এবং একটি application cache-এ সংরক্ষিত হয়। ওই ১০ মিনিটে প্রতিটি ভিজিটর সংরক্ষিত ফলাফল তাৎক্ষণিক পায়।
- দাম অল্প সময়ের জন্য ক্যাশ হয়, এবং আপনি কোনো পণ্য সম্পাদনা করলে ক্যাশ খালি হয়, তাই গ্রাহকরা দীর্ঘ সময় পুরোনো দাম দেখেন না।
- চেকআউটের স্টক কখনও ক্যাশ হয় না। কেউ “Buy” চাপলে অ্যাপ প্রকৃত ডেটাবেস পরীক্ষা করে, তাই যে পণ্য এইমাত্র শেষ হয়েছে তা বিক্রি করতে পারে না।
- কার্ট ও অ্যাকাউন্ট পেজ শেয়ার করা ক্যাশে কখনও রাখা হয় না, কারণ সেগুলো ব্যক্তিগত।
ফল: হোম পেজ দ্রুত, ডেটাবেসের কাজ অনেক কম, এবং অর্থ বা গোপনীয়তার সাথে জড়িত কিছুই কখনও পুরোনো থাকে না।
মূল শব্দ
| শব্দ | অর্থ |
|---|---|
| Cache hit / miss | ডেটা ক্যাশে পাওয়া গেছে / উৎস থেকে আনতে হয়েছে। |
| TTL (time to live) | একটি ক্যাশ করা কপি কতক্ষণ তাজা বলে গণ্য হয়। |
| Stale data | একটি ক্যাশ করা কপি যা পুরোনো হয়ে গেছে। |
| Invalidation | মূল ডেটা বদলানোর কারণে ইচ্ছে করে একটি ক্যাশ করা কপি সরানো। |
| Cache busting | ফাইল বদলালে তার নাম বা URL বদলানো, যাতে ক্যাশ নতুন ভার্সন আনে। |
| Cache-Control | HTTP হেডার, যা ব্রাউজার ও CDN-কে বলে একটি রেসপন্স কীভাবে ক্যাশ করতে হবে। |
| Hard refresh | ব্রাউজারকে ক্যাশ উপেক্ষা করতে বলে পেজ আবার লোড করা। |
| Redis | একটি জনপ্রিয় ইন-মেমরি ডেটা স্টোর, যা প্রায়ই application cache হিসেবে ব্যবহৃত হয়। |
সাধারণ ভুল ধারণা
- “Caching সবসময় ভালো।” ভুল জিনিস ক্যাশ করলে সত্যিকারের বাগ হয়: পুরোনো দাম, নতুন পোস্ট না দেখা, অথবা সবচেয়ে খারাপ ক্ষেত্রে একজন ব্যবহারকারীর ব্যক্তিগত পেজ অন্যজনকে দেখানো। ইচ্ছে করে ক্যাশ করুন।
- “পুরোনো ভার্সন দেখলে মানে আমার আপডেট ব্যর্থ।” সাধারণত তা নয়। কিছু ভাঙা ধরে নেওয়ার আগে হার্ড রিফ্রেশ (Ctrl+Shift+R, বা Mac-এ Cmd+Shift+R) বা প্রাইভেট উইন্ডোতে দেখুন।
- “Caching একটি ধীর অ্যাপ ঠিক করে।” এটি বারবার আসা অনুরোধের জন্য ধীরগতি লুকায়। প্রথম অনুরোধটি এখনও ধীর, এবং মূল সমস্যা যদি ডেটাবেসে ইনডেক্স না থাকা হয়, সেটিও ঠিক করুন।
- “যতদিন সম্ভব সবকিছু ক্যাশ করা উচিত।” দীর্ঘ ক্যাশ সময় সেসব ফাইলের জন্য ভালো, যাদের বদলালে নতুন নাম হয়। HTML পেজ ও ডেটার জন্য ছোট সময় নিরাপদ।
- “আমার ক্যাশ খালি করলে সবার জন্য ঠিক হবে।” এটি শুধু আপনার ব্রাউজার খালি করে। ভিজিটর ও CDN ক্যাশের নিজস্ব কপি এখনও থাকে।
আপনার AI বিল্ডারকে কী জিজ্ঞেস করবেন
- “এই অ্যাপের কোন অংশগুলো ধীর, এবং কোনগুলো নিরাপদে ক্যাশ করা যায়?”
- “[ট্রেন্ডিং তালিকা / API ফলাফল] [N] মিনিটের জন্য ক্যাশ করো, এবং মূল ডেটা বদলালে সেটি খালি করো।”
- “নিশ্চিত করো ব্যক্তিগত বা অ্যাকাউন্ট ডেটাসহ কোনো পেজ CDN বা শেয়ার করা ক্যাশ দ্বারা ক্যাশ হতে পারবে না।”
- “ফিঙ্গারপ্রিন্টযুক্ত স্ট্যাটিক ফাইলের জন্য দীর্ঘ এবং HTML-এর জন্য ছোট ক্যাশ সময় সেট করো।”
- “[বাইরের API] থেকে রেসপন্স ক্যাশ করো যাতে প্রতিটি পেজ লোডে সেটি না ডাকি — এবং বলো ডেটা কতটা পুরোনো হতে পারে।”
- “প্রকাশ করার পর আমি পুরোনো ভার্সন দেখছি। এটি কি আমার ব্রাউজার ক্যাশ, নাকি কিছু ডিপ্লয় হয়নি?”
Mythex-এ Caching
Mythex অ্যাপে একটি আপডেট প্রকাশ করার পর ডকস উল্লেখ করে যে CDN ক্যাশ কিছুক্ষণ পিছিয়ে থাকতে পারে, এবং পাবলিক URL-এ হার্ড রিফ্রেশ দিলে নতুন ভার্সন দেখা যায় — দেখুন কীভাবে প্রকাশ করবেন। হোস্টিং সীমা পাতাটিও স্ট্যাটিক অ্যাসেট ক্যাশ করার পরামর্শ দেয়, কারণ হোস্টিং, ডেটাবেস সময় ও ব্যান্ডউইথের দাম আপনার ক্রেডিট ব্যালেন্স থেকে কাটা হয়। এর বাইরে — কোয়েরির ফল বা API রেসপন্স ক্যাশ করা — এমন কিছু যা আপনি এজেন্টকে আপনার অ্যাপে তৈরি করতে বলেন।
সংশ্লিষ্ট পড়া: CDN কী, ওয়েবসাইট কীভাবে দ্রুত করবেন এবং রেট লিমিটিং কী।
প্রশ্নোত্তর
সহজ ভাষায় caching কী?
Caching মানে এমন কিছুর একটি কপি সংরক্ষণ করা, যা পেতে আগে সময় বা খরচ বেশি লাগত, যাতে পরের বার সেটি দরকার হলে সংরক্ষিত কপি থেকে দ্রুত দেওয়া যায়। অ্যাপকে দ্রুত ও চালাতে সস্তা করতে ব্রাউজার, CDN, সার্ভার ও ডেটাবেস সবাই ক্যাশ ব্যবহার করে।
ওয়েবসাইট আপডেট করার পরও কেন পুরোনো ভার্সন দেখি?
আপনার ব্রাউজার বা একটি CDN সম্ভবত পুরোনো ফাইলের সংরক্ষিত কপি দেখাচ্ছে। হার্ড রিফ্রেশ (Windows-এ Ctrl+Shift+R, Mac-এ Cmd+Shift+R) সাধারণত এটি ঠিক করে। ভিজিটরদের জন্য ভালোভাবে তৈরি সাইট আপডেট করা ফাইলকে নতুন নাম দেয়, যাতে ক্যাশ নিজে থেকেই নতুন ভার্সন আনে।
ক্যাশ খালি করলে কী হয়?
ব্রাউজারের ক্যাশ খালি করলে ব্রাউজারে জমা থাকা ফাইল ও পেজের কপি মুছে যায়, তাই পরের বার সবকিছু নতুন করে ডাউনলোড হয়। ভাঙা বা পুরোনো দেখানো পেজ ঠিক হতে পারে, এবং এরপর প্রথমবার পেজ একটু ধীরে লোড হবে।
Caching কি সমস্যা তৈরি করতে পারে?
হ্যাঁ। প্রধান ঝুঁকি হলো পুরোনো ডেটা দেওয়া — পুরোনো দাম, অচল স্টক লেভেল — অথবা আরও খারাপ, একজন ব্যবহারকারীর ব্যক্তিগত পেজ ক্যাশ করে অন্য কাউকে দেখানো। ভালো caching নিয়ম ঠিক করে কী ক্যাশ হবে, কতক্ষণের জন্য, এবং শেয়ার করা ক্যাশে ব্যক্তিগত ডেটা কখনও রাখা হবে না।