ক্যাশ কী — CDN কোন দুইটা রিকোয়েস্টকে "একই" ধরে

গল্পে বুঝি

মিরপুরের এক গলিতে ফারাবির দর্জির দোকান। ঈদের আগে ভিড়, তাই ফারাবি একটা নিয়ম করেছে: প্রতিটা অর্ডারের একটা স্লিপ, তাতে লেখা থাকে কাস্টমারের নাম আর মাপ, আর সেই স্লিপ দিয়েই তাকের খোপে কাপড় রাখা হয়। কেউ এসে বলে “সিনার পাঞ্জাবি, বুক ৪০, লম্বা ৪২”, কর্মচারী খোপে খোঁজে, স্লিপ মিলে গেলে সাথে সাথে বানানো পাঞ্জাবি হাতে দেয়। না মিললে নতুন করে কাটা-সেলাই শুরু, তিন দিন।

সমস্যা শুরু হলো যখন কাস্টমাররা একই জিনিস একটু আলাদাভাবে বলতে লাগল। সিনা একদিন বলল “লম্বা ৪২, বুক ৪০”, আরেকদিন “বুক ৪০, লম্বা ৪২, মোবাইল ০১৭…”। কর্মচারী অক্ষরে অক্ষরে স্লিপ মেলায়, তাই প্রতিবার নতুন স্লিপ, নতুন খোপ, নতুন করে সেলাই। এক মাসে দেখা গেল একই মাপের সাতটা পাঞ্জাবি বানানো হয়ে গেছে, তাক ভরা, অথচ কোনোটাই “মেলেনি”। মোবাইল নাম্বারটা মাপের কোনো অংশ না, কিন্তু স্লিপে লেখা থাকায় সেটাও মেলানোর অংশ হয়ে গিয়েছিল।

উল্টো ভুলও হলো। ফারাবি তাড়াহুড়োয় একবার নিয়ম করল “শুধু নাম দেখলেই চলবে”। ফলে দুইজন আলাদা “রাজি” এল, একজন খাটো আরেকজন লম্বা, আর লম্বা রাজি পেয়ে গেল খাটো রাজির পাঞ্জাবি। কম জিনিস মেলালে ভুল মানুষের হাতে ভুল জিনিস যায়, বেশি জিনিস মেলালে কিছুই মেলে না। ফারাবি শেষে ঠিক করল: নাম আর মাপ মেলাবে, মাপের ক্রম আগে থেকে সাজিয়ে লিখবে, আর মোবাইল নাম্বার স্লিপে থাকবে কিন্তু মেলানোর সময় দেখবে না।

মিলিয়ে নিই: স্লিপে যা যা মেলানো হয় সেটাই cache key। খোপে বানানো পাঞ্জাবি হলো ক্যাশ করা রেসপন্স, স্লিপ মিলে যাওয়া cache HIT, তিন দিনের নতুন সেলাই origin fetch / MISS। মাপের ক্রম বদলে নতুন স্লিপ হওয়া হলো query string ক্রমের কারণে ফ্র্যাগমেন্টেশন, মোবাইল নাম্বার হলো utm_source বা fbclid-এর মতো ট্র্যাকিং প্যারামিটার, আর সাতটা একই পাঞ্জাবি হলো কমে যাওয়া hit ratio। “শুধু নাম দেখলেই চলবে” হলো খুব ঢিলা ক্যাশ কী, যার ফল এক ইউজারের কন্টেন্ট আরেক ইউজারের কাছে যাওয়া। ক্রম সাজিয়ে লেখা হলো query string নরমালাইজেশন, আর নাম্বার রেখে না-মেলানো হলো প্যারামিটার ক্যাশ কী থেকে বাদ দেওয়া, কিন্তু origin-এ পাঠানো।

ক্যাশ কী আসলে কী

CDN-এর ক্যাশ একটা বিশাল key-value স্টোর। ভ্যালু হলো একটা রেসপন্স (হেডার + বডি), আর কী হলো রিকোয়েস্টের কিছু অংশ থেকে বানানো একটা স্ট্রিং। নতুন রিকোয়েস্ট এলে CDN একই নিয়মে কী বানায়, স্টোরে খোঁজে; পেলে HIT, না পেলে MISS।

ডিফল্ট কী প্রায় সব CDN-এ মোটামুটি এক:

scheme + host + path + query string

https://baytalhikma.org/books/algebra.jpg?w=800
└─┬─┘   └──────┬──────┘└───────┬───────┘└─┬─┘
scheme       host            path       query

তাই নিচের তিনটা URL CDN-এর কাছে তিনটা আলাদা অবজেক্ট, যদিও origin হয়তো তিনটায় একই বাইট ফেরত দেয়:

https://baytalhikma.org/books/algebra.jpg
https://baytalhikma.org/books/algebra.jpg?w=800
https://baytalhikma.org/books/algebra.jpg?w=800&utm_source=facebook

ক্যাশ কী ডিজাইনের পুরো খেলা দুইটা ভুলের মাঝে ভারসাম্য:

ভুল	কী হয়	কীভাবে ধরা পড়ে
কী-তে বেশি জিনিস	একই কন্টেন্টের অনেক কপি, hit ratio কম, origin-এ চাপ	origin বিল বা লোড বেশি, MISS বেশি
কী-তে কম জিনিস	আলাদা কন্টেন্ট একই কী পায়, ভুল ইউজার ভুল রেসপন্স পায়	ইউজার অভিযোগ, কখনো ডেটা লিক

প্রথমটা টাকা আর গতি নষ্ট করে। দ্বিতীয়টা বিপজ্জনক: কারো অ্যাকাউন্ট পেজ, কারো ভাষা, কারো কারেন্সি অন্য কারো কাছে চলে যায়।

Hit ratio-র অঙ্ক: ফ্র্যাগমেন্টেশন কেন মারাত্মক

ধরুন /books/algebra.jpg দিনে ১০,০০০ বার চাওয়া হয়, TTL এক ঘণ্টা, আর একটা এজ সার্ভার। কী ঠিক থাকলে প্রতি ঘণ্টায় একবার MISS, বাকি সব HIT: দিনে ২৪টা MISS, hit ratio প্রায় ৯৯.৮%।

এবার মার্কেটিং টিম প্রতিটা লিংকে utm_campaign আর fbclid জুড়ে দিল। fbclid প্রতিটা ক্লিকে আলাদা। এখন প্রায় প্রতিটা রিকোয়েস্টের কী আলাদা, তাই প্রায় প্রতিটা রিকোয়েস্ট MISS। একই ছবি, একই বাইট, কিন্তু hit ratio ৯৯.৮% থেকে নেমে কাছাকাছি শূন্যে। origin হঠাৎ ৪০০ গুণ বেশি রিকোয়েস্ট দেখে।

এই উদাহরণের সংখ্যাগুলো আনুমানিক, কিন্তু প্যাটার্নটা বাস্তব: অনন্য কী-র সংখ্যা যত বাড়ে, প্রতিটা কী-তে রিকোয়েস্ট তত কমে, আর TTL শেষ হওয়ার আগে দ্বিতীয়বার কেউ না চাইলে ক্যাশ করা কপি কোনো কাজেই আসে না। একাধিক PoP থাকলে সমস্যা আরও বাড়ে, কারণ প্রতিটা PoP-এর ক্যাশ আলাদা (চ্যাপ্টার ২)।

ক্যাশ কাজে লাগে যখন:
  একই কী-তে TTL-এর ভেতরে দ্বিতীয় রিকোয়েস্ট আসে

প্রতি কী-তে রিকোয়েস্ট ≈ মোট রিকোয়েস্ট ÷ (অনন্য কী × PoP সংখ্যা)

Query string: সবচেয়ে বড় ফ্র্যাগমেন্টেশনের উৎস

ক্রম

?w=800&fmt=webp আর ?fmt=webp&w=800 আপনার অ্যাপের কাছে একই, কিন্তু স্ট্রিং হিসেবে আলাদা। বেশিরভাগ CDN-এ query string সাজানোর (sort) একটা অপশন থাকে। Cloudflare-এ “sort query string” ফিচারটা সব প্ল্যানে আছে (২০২৬ সালের অক্টোবর অনুযায়ী তাদের cache key ডক)। নিজের CDN হলে নিজেই নরমালাইজ করুন (চ্যাপ্টার ১৩)।

ট্র্যাকিং প্যারামিটার

utm_*, fbclid, gclid, msclkid, mc_eid — এগুলো শুধু অ্যানালিটিক্সের জন্য, origin-এর রেসপন্স বদলায় না। এগুলো কী থেকে বাদ দিন। সতর্কতা: বাদ দেওয়া মানে origin-এ পাঠানো বন্ধ করা না-ও হতে পারে। দুইটা আলাদা প্রশ্ন:

1. প্যারামিটারটা ক্যাশ কী-তে থাকবে কিনা?
2. প্যারামিটারটা origin-এ ফরোয়ার্ড হবে কিনা?

অ্যানালিটিক্স সাধারণত ব্রাউজারের JavaScript থেকে URL পড়ে, তাই origin-এ না পাঠালেও চলে। কিন্তু কোনো সার্ভার-সাইড লগ যদি এগুলোর উপর নির্ভর করে, তাহলে “কী থেকে বাদ, কিন্তু ফরোয়ার্ড” বেছে নিন।

Include-list বনাম exclude-list

পদ্ধতি	মানে	কখন
Exclude-list	এগুলো বাদে সব কী-তে	অজানা প্যারামিটার অনেক, অ্যাপ নতুন প্যারামিটার যোগ করে
Include-list	শুধু এগুলো কী-তে	আপনি জানেন কোন প্যারামিটার রেসপন্স বদলায় (w, fmt, page)
Ignore all	query string পুরো বাদ	স্ট্যাটিক অ্যাসেট যেখানে query কখনো রেসপন্স বদলায় না

Include-list নিরাপদ মনে হয়, কিন্তু একটা ফাঁদ আছে: অ্যাপে কেউ ?lang=bn যোগ করল, CDN কনফিগ আপডেট হলো না, এখন lang কী-তে নেই কিন্তু origin সেটা দেখে ভাষা বদলায়। ফলে প্রথম যে ভাষায় রেসপন্স ক্যাশ হলো, সবাই সেটাই পায়। কী থেকে যা বাদ দেবেন, origin-এ সেটা রেসপন্স বদলাতে পারবে না — এই নিয়ম ভাঙলেই ভুল কন্টেন্ট।

Cookie ও ক্যাশ কী

Cookie হলো প্রতি-ইউজার ডেটা। ডিফল্টে বেশিরভাগ CDN cookie-কে কী-তে রাখে না, বরং অনেক CDN এমন রিকোয়েস্ট বা রেসপন্সকে ক্যাশ করতেই চায় না যাতে cookie আছে (বিশেষ করে রেসপন্সে Set-Cookie)। এটা ইচ্ছাকৃত নিরাপত্তা।

তিনটা প্যাটার্ন:

1. পুরো cookie কী-তে রাখা — কার্যত প্রতি ইউজারের আলাদা কপি। ক্যাশ প্রায় অকেজো। এড়িয়ে চলুন।
2. একটা নির্দিষ্ট cookie-র ভ্যালু কী-তে — যেমন currency=BDT বা ab_bucket=b। ভ্যালু কয়েকটা মাত্র, তাই কপিও কয়েকটা। এটা ঠিক আছে।
3. cookie আছে কিনা সেটা দেখে বাইপাস — session cookie থাকলে ক্যাশ বাইপাস, না থাকলে (লগআউট ইউজার) ক্যাশ থেকে। ব্লগ বা নিউজ সাইটে খুব কাজের (চ্যাপ্টার ৯)।

# Self-hosted edge: key on the currency cookie only, bypass for logged-in users
proxy_cache_key "$scheme$host$uri$is_args$args|cur=$cookie_currency";
proxy_cache_bypass $cookie_session;
proxy_no_cache     $cookie_session;

Vary: origin যখন নিজেই বলে “কী-তে এটাও রাখো”

Vary হলো origin-এর রেসপন্স হেডার, যেটা ক্যাশকে বলে: “এই রেসপন্স এই রিকোয়েস্ট হেডারগুলোর ভ্যালুর উপর নির্ভর করে, তাই ওগুলো মিলিয়ে তবেই দেবে।” (RFC 9111)

HTTP/2 200
content-type: text/html
content-encoding: br
vary: Accept-Encoding

এর মানে: যে রিকোয়েস্ট Accept-Encoding: br পাঠিয়েছিল, তার জন্য এই কপি। gzip চাওয়া কারো জন্য আলাদা কপি লাগবে।

Vary-র বিস্ফোরণ

Vary কী-কে কার্যত রিকোয়েস্ট হেডারের পুরো ভ্যালু দিয়ে বাড়িয়ে দেয়। তাই কিছু Vary ক্যাশ শেষ করে দেয়:

Vary	সমস্যা
Vary: User-Agent	হাজার হাজার আলাদা UA স্ট্রিং, প্রতিটায় আলাদা কপি। ক্যাশ প্রায় শূন্য
Vary: Cookie	প্রতি ইউজার আলাদা কপি
Vary: *	কখনো মেলে না, কার্যত ক্যাশ না করার সমান
Vary: Accept-Language	bn-BD,bn;q=0.9,en;q=0.8 এর মতো অগণিত রূপ
Vary: Accept-Encoding	ঠিক আছে, যদি CDN এটা নরমালাইজ করে (নিচে)

অনেক CDN নিজের সুরক্ষার জন্য কিছু Vary ভ্যালু দেখলে রেসপন্স ক্যাশই করে না বা Vary উপেক্ষা করে। আচরণ ভেন্ডরভেদে আলাদা, তাই “আমার Vary: User-Agent দিয়ে মোবাইল/ডেস্কটপ আলাদা হবে” ধরে নেবেন না। মোবাইল আর ডেস্কটপ আলাদা করতে চাইলে পুরো UA না, বরং CDN-এর device type ফিচার ব্যবহার করুন, যেটা UA থেকে mobile / desktop / tablet এর মতো তিনটা বাকেট বানায়।

Accept-Encoding নরমালাইজেশন

ব্রাউজাররা Accept-Encoding বিভিন্নভাবে পাঠায়: gzip, deflate, br, br, gzip, gzip, deflate, br, zstd। কাঁচা ভ্যালু কী-তে গেলে একই কন্টেন্টের ডজন কপি। ভালো CDN এটাকে নরমালাইজ করে কয়েকটা বাকেটে (যেমন br, gzip, কিছুই না) নামিয়ে আনে। নিজের এজ চালালে এটা আপনার কাজ:

map $http_accept_encoding $enc_bucket {
    default   "";
    ~*zstd    "zstd";
    ~*br      "br";
    ~*gzip    "gzip";
}
proxy_cache_key "$scheme$host$request_uri|enc=$enc_bucket";

ভাষা আর দেশ

Accept-Language পুরোটা কী-তে না রেখে প্রথম ভাষাটা নিন, অথবা ভাষা URL-এ রাখুন (/bn/..., /en/...)। URL-এ রাখাই সবচেয়ে পরিষ্কার: শেয়ার করা লিংক ঠিক ভাষায় খোলে, ক্যাশ কী সহজ, SEO-ও খুশি। দেশভিত্তিক কন্টেন্ট (কারেন্সি, দাম) হলে CDN-এর geo ফিচার দিয়ে দেশ কোডটা কী-তে রাখুন, IP না।

ছোট ছোট পার্থক্য যা আলাদা কী বানায়

পার্থক্য	উদাহরণ	কী করবেন
হোস্ট	baytalhikma.org বনাম www.baytalhikma.org	একটা ক্যানোনিকাল হোস্ট, অন্যটা 301
স্কিম	http বনাম https	সব HTTPS-এ রিডাইরেক্ট
শেষের স্ল্যাশ	/books বনাম /books/	origin-এ একটা থেকে অন্যটায় 301
কেস	/Books/Algebra.JPG বনাম /books/algebra.jpg	path কেস-সেনসিটিভ, লিংকগুলো এক রকম রাখুন
এনকোডিং	%E0%A6%AC বনাম কাঁচা ইউনিকোড	একই রকম এনকোড করে লিংক বানান
খালি query	/a.css? বনাম /a.css	কিছু CDN আলাদা ধরে, লিংকে ফালতু ? রাখবেন না

Path-এর কেস বদলানো সাধারণত ঠিক না, কারণ origin /Books আর /books-এ আলাদা জিনিস দিতে পারে। এখানে সমাধান CDN-এ না, লিংক বানানোর জায়গায়।

ক্যাশ কী ঢিলা হলে: ভুল কন্টেন্ট, এমনকি লিক

সবচেয়ে বিপজ্জনক ভুল উল্টো দিকে। ধরুন origin /account পেজে লগইন ইউজারের নাম দেখায়, cookie দেখে। কেউ CDN-এ “সব HTML এক ঘণ্টা ক্যাশ করো” রুল দিল। কী-তে cookie নেই। প্রথম যে লগইন ইউজার /account চাইল, তার পেজ ক্যাশ হলো, পরের এক ঘণ্টা সবাই তার নাম, ইমেইল, অর্ডার দেখল।

ভালো ক্যাশ কী-র চেকলিস্ট

1. রেসপন্স যা যা দিয়ে বদলায়, সব কী-তে আছে (অথবা URL-এ আছে)।
2. রেসপন্স যা দিয়ে বদলায় না, তা কী-তে নেই (ট্র্যাকিং প্যারামিটার, অপ্রয়োজনীয় হেডার)।
3. query string সাজানো বা include-list করা।
4. Vary-তে শুধু Accept-Encoding (নরমালাইজড), দরকার হলে ছোট বাকেটের কিছু; কখনো User-Agent বা Cookie না।
5. একটা ক্যানোনিকাল হোস্ট আর স্কিম।
6. প্রতি-ইউজার রেসপন্স শেয়ার্ড ক্যাশে ঢোকে না।
7. কী-র নিয়ম কোথাও লেখা আছে, যাতে অ্যাপে নতুন প্যারামিটার যোগ হলে কেউ CDN কনফিগও দেখে।

হাতে-কলমে পরীক্ষা: দুইটা URL কি একই কী পায়?

সবচেয়ে সহজ টেস্ট: প্রথম URL দিয়ে ক্যাশ গরম করুন, তারপর দ্বিতীয় URL চেয়ে দেখুন HIT আসে কিনা। হেডার পড়ার বিস্তারিত চ্যাপ্টার ৫-এ।

# Warm the cache, then probe a variant
curl -s -o /dev/null https://baytalhikma.org/books/algebra.jpg
curl -s -o /dev/null -D - "https://baytalhikma.org/books/algebra.jpg?utm_source=fb" \
  | grep -iE '^(age|cf-cache-status|x-cache|cache-status):'

cf-cache-status: MISS
age: 0

(আউটপুট দেখানোর জন্য বানানো।) utm_source যোগ করায় MISS, মানে প্যারামিটারটা কী-তে আছে। কী থেকে বাদ দেওয়ার পর একই টেস্ট:

cf-cache-status: HIT
age: 37

এবার উল্টো দিক যাচাই, যেটা বেশি জরুরি: যে জিনিস রেসপন্স বদলায়, সেটা বদলালে কি সত্যিই আলাদা রেসপন্স আসে?

curl -s https://baytalhikma.org/prices -H 'Cookie: currency=BDT' | grep -o 'BDT\|USD' | head -1
curl -s https://baytalhikma.org/prices -H 'Cookie: currency=USD' | grep -o 'BDT\|USD' | head -1

দুইবারই BDT এলে ক্যাশ কী-তে currency নেই, অথচ origin সেটা দেখে রেসপন্স বদলায়: ঢিলা কী।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

লক্ষণ	নিশ্চিত করার উপায়	সমাধান
hit ratio খুব কম, origin লোড বেশি	CDN লগ বা অ্যানালিটিক্সে টপ URL দেখুন; একই path অনেক আলাদা query নিয়ে আছে কিনা	ট্র্যাকিং প্যারামিটার কী থেকে বাদ, query সাজানো
মার্কেটিং ক্যাম্পেইনের পর origin ডাউন	ক্যাম্পেইন লিংকে fbclid/utm_* আছে কিনা, ওই সময়ের MISS রেট	ওই প্যারামিটার কী থেকে বাদ
একটা ফাইল কখনো HIT হয় না	curl -sI URL চালিয়ে রেসপন্সে Vary: User-Agent বা Vary: * আছে কিনা দেখুন	origin থেকে খারাপ Vary সরান
একজন ইউজার অন্যজনের নাম/কার্ট দেখছে	curl -sI URL এ Cache-Control দেখুন; CDN-এ HTML-এর জন্য “cache everything” রুল আছে কিনা	প্রতি-ইউজার রেসপন্সে private/no-store; রুলটা সেশন cookie দেখে বাইপাস করুক; পুরো পাথ পার্জ
ভুল ভাষা বা কারেন্সি দেখাচ্ছে	উপরের দুই-cookie টেস্ট, বা দুই Accept-Language দিয়ে একই টেস্ট	ভাষা URL-এ নিন, বা ভ্যালুটা কী-তে রাখুন
?v=43 দিলেও পুরনো JS আসছে	“ignore query string” চালু কিনা	ফাইলনেমে হ্যাশ দিন, বা ওই পাথে query কী-তে রাখুন
www আর non-www-তে আলাদা কন্টেন্ট	দুই হোস্টে curl -sI, দুইটার age আলাদা কিনা	একটা থেকে অন্যটায় 301
মোবাইলে ডেস্কটপ লেআউট	origin UA দেখে HTML বদলায়, কিন্তু কী-তে ডিভাইস নেই	রেসপন্সিভ ডিজাইন, অথবা CDN-এর device type কী-তে

মূল শিক্ষা

1. ক্যাশ কী ঠিক করে কোন দুইটা রিকোয়েস্ট “একই”। ডিফল্টে scheme, host, path আর পুরো query string।
2. বেশি জিনিস কী-তে মানে কম HIT; কম জিনিস মানে ভুল কন্টেন্ট। দ্বিতীয়টা বেশি বিপজ্জনক।
3. ট্র্যাকিং প্যারামিটার সবচেয়ে বড় ফ্র্যাগমেন্টেশন। কী থেকে বাদ দিন, query সাজান।
4. কী থেকে যা বাদ দেবেন, origin-এ সেটা রেসপন্স বদলাতে পারবে না।
5. Vary: User-Agent, Vary: Cookie, Vary: * ক্যাশ মেরে ফেলে। ছোট বাকেট (ডিভাইস টাইপ, দেশ, নরমালাইজড এনকোডিং) ব্যবহার করুন।
6. ভাষা, ভার্সন, ভ্যারিয়েন্ট যতটা পারা যায় URL-এ রাখুন। সবচেয়ে সহজ, সবচেয়ে কম ভুল।
7. প্রাইভেট রেসপন্স ক্যাশ কী দিয়ে না, Cache-Control দিয়ে রক্ষা করুন।
8. দুই দিকেই টেস্ট করুন: অপ্রাসঙ্গিক জিনিস বদলালে HIT, প্রাসঙ্গিক জিনিস বদলালে আলাদা রেসপন্স।