পার্জ ও ইনভ্যালিডেশন — ক্যাশ থেকে পুরনো জিনিস সরানো

গল্পে বুঝি

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

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

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

মিলিয়ে নিই: ছাপাখানা হলো origin, জোনাল ডিপো shield / মিড-টিয়ার ক্যাশ, হকারের ঝোলা এজ ক্যাশ। “সব ফেলে দাও” হলো purge everything, আর গেটের লাইন origin stampede। একটা নির্দিষ্ট কাগজ বদলানো হলো URL দিয়ে পার্জ, লেবেল দিয়ে তুলে নেওয়া ট্যাগ বা surrogate key দিয়ে পার্জ। ফারাবির ভাঁজ করে রাখা পুরনো কপি হলো সফট পার্জ আর stale-while-revalidate / stale-if-error। বাসায় চলে যাওয়া কাগজ হলো ব্রাউজারের ক্যাশ, যা CDN পার্জ করতে পারে না, আর “দ্বিতীয় সংস্করণ” লেখা মাস্টহেড হলো ভার্সনড URL, যা পার্জের দরকারই ফুরিয়ে দেয়।

কেন এটা কঠিন

পুরনো রসিকতা: কম্পিউটার সায়েন্সে কঠিন কাজ দুইটা, ক্যাশ ইনভ্যালিডেশন আর নাম রাখা। CDN-এ ইনভ্যালিডেশন আরও কঠিন, কারণ:

1. কপি অনেক জায়গায়। প্রতিটা PoP-এ, প্রতিটা PoP-এর ভেতরে অনেক সার্ভারে, shield-এ, আর CDN-এর বাইরে ব্রাউজার আর প্রক্সিতে।
2. পার্জ একটা ডিস্ট্রিবিউটেড অপারেশন। API কল সফল মানে CDN অনুরোধটা পেয়েছে, সব জায়গায় পৌঁছেছে এমন না। যেমন Cloudflare-এর ডক (২০২৬ সালের অক্টোবর) স্পষ্ট বলে, পার্জ API-র 200 মানে শুধু অনুরোধ গৃহীত হয়েছে; যাচাই করতে আবার রিকোয়েস্ট করে দেখুন cf-cache-status আর HIT নেই।
3. কোন কোন URL বদলেছে, সেটা জানাই কঠিন। একটা বইয়ের দাম বদলালে বইয়ের পেজ, ক্যাটাগরি পেজ, হোমপেজ, সার্চ রেজাল্ট, API রেসপন্স, RSS — সব পুরনো।
4. CDN-এর বাইরের কপি আপনার নিয়ন্ত্রণে নেই।

তাই এই চ্যাপ্টারের মূল কথা আগেই বলে রাখি: পার্জ জরুরি অবস্থার টুল, স্বাভাবিক ডিপ্লয়ের পদ্ধতি না। স্বাভাবিক পদ্ধতি হলো এমন URL আর TTL ডিজাইন করা যাতে পার্জ লাগেই না।

পার্জের ধরন

ধরন	কী সরায়	কখন
URL / single file	একটা নির্দিষ্ট URL (একটা ক্যাশ কী)	একটা পেজ বা ফাইল ভুল
Prefix / wildcard	একটা পাথের নিচের সব (/books/)	একটা সেকশন বদলেছে
Hostname	একটা হোস্টের সব	একটা সাবডোমেইন রিডিপ্লয়
Tag / surrogate key	যেসব রেসপন্সে নির্দিষ্ট ট্যাগ আছে	একটা ডেটা বদলালে যত পেজে সেটা আছে
Everything	পুরো জোন	শেষ ভরসা

Cloudflare-এ ২০২৬ সালের অক্টোবর অনুযায়ী URL, hostname, tag, prefix আর everything সব প্ল্যানেই পাওয়া যায়, তবে প্ল্যানভেদে রেট লিমিট খুব আলাদা (যেমন ফ্রি প্ল্যানে URL ছাড়া বাকি ধরনগুলো মিনিটে মাত্র কয়েকটা অনুরোধ)। অন্য ভেন্ডরে কোনো কোনো ধরন উঁচু প্ল্যানে বা আলাদা খরচে। CI-তে পার্জ বসানোর আগে নিজের ভেন্ডরের লিমিট দেখে নিন, নইলে বড় ডিপ্লয়ের দিন পার্জ নিজেই রেট লিমিটে আটকে যাবে।

URL পার্জের ফাঁদ: ক্যাশ কী

URL পার্জ আসলে একটা ক্যাশ কী সরায়। চ্যাপ্টার ৪ মনে করুন: একই URL-এর কয়েকটা কপি থাকতে পারে আলাদা Accept-Encoding, ডিভাইস টাইপ, query string বা ভাষার জন্য। https://baytalhikma.org/books/algebra পার্জ করলে ?utm_source=fb ওয়ালা কপি থেকে যেতে পারে, অথবা মোবাইল ভ্যারিয়েন্ট থেকে যেতে পারে। CDN ভেদে আচরণ আলাদা; কেউ সব ভ্যারিয়েন্ট সরায়, কেউ শুধু ঠিক মেলা কী। নিশ্চিত না হলে পার্জের পর বিভিন্ন ভ্যারিয়েন্ট দিয়ে টেস্ট করুন, অথবা prefix বা tag পার্জ ব্যবহার করুন।

ট্যাগ দিয়ে পার্জ: সবচেয়ে কাজের টুল

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

GET /books/algebra          → Cache-Tag: book-42, author-7, category-math
GET /categories/math        → Cache-Tag: category-math, book-42, book-43, book-51
GET /authors/khwarizmi      → Cache-Tag: author-7, book-42, book-44
GET /                       → Cache-Tag: home, book-42, book-51

বই ৪২-এর দাম বদলালে শুধু book-42 পার্জ করুন, চারটা পেজই যাবে, অন্য হাজার পেজ ক্যাশে থাকবে।

হেডারের নাম ভেন্ডরভেদে আলাদা (২০২৬ সালের অক্টোবর অনুযায়ী, নিজের ভেন্ডরের ডকে মিলিয়ে নিন):

ভেন্ডর	হেডার	নোট
Cloudflare	Cache-Tag	ইউজারের কাছে যাওয়ার আগে মুছে ফেলে; একটা রেসপন্সে সব ট্যাগ মিলিয়ে ১৬ KB পর্যন্ত; ট্যাগ case-insensitive, স্পেস চলবে না
Fastly	Surrogate-Key	ইউজারের কাছে যাওয়ার আগে মুছে ফেলে (debug হেডার পাঠালে ছাড়া)
অন্যরা	Surrogate-Key, Cache-Tag বা নিজস্ব	কেউ কেউ শুধু উঁচু প্ল্যানে

origin-এ ট্যাগ বসানো সাধারণত সহজ, কারণ রেন্ডার করার সময় অ্যাপ জানেই কোন ডেটা ব্যবহার হলো:

// Collect tags while rendering, emit them once
func renderBook(w http.ResponseWriter, b Book) {
	tags := []string{"book-" + strconv.Itoa(b.ID), "author-" + strconv.Itoa(b.AuthorID)}
	for _, c := range b.Categories {
		tags = append(tags, "category-"+c.Slug)
	}
	w.Header().Set("Cache-Tag", strings.Join(tags, ","))
	w.Header().Set("Cache-Control", "public, s-maxage=86400, max-age=60")
	// ... render template
}

আর ডেটা বদলানোর জায়গায় পার্জ:

// After the DB write commits, purge everything that showed this book
func onBookUpdated(ctx context.Context, id int) error {
	return cdn.PurgeTags(ctx, "book-"+strconv.Itoa(id))
}

“সব পার্জ” কেন বিপজ্জনক

একটা জনপ্রিয় সাইট, hit ratio ৯৮%। মানে origin ১০০টা রিকোয়েস্টের মাত্র ২টা দেখে। “purge everything” চাপার পরের মুহূর্তে hit ratio প্রায় শূন্য: origin হঠাৎ প্রায় ৫০ গুণ ট্রাফিক দেখে (১০০ ÷ ২)। সংখ্যাটা উদাহরণ, কিন্তু অনুপাতটাই আসল বিপদ: hit ratio যত বেশি, সব পার্জের ধাক্কা তত বড়।

ধাক্কা কমানোর উপায়:

1. Origin shield / tiered cache (চ্যাপ্টার ৭): সব PoP origin-এ না গিয়ে একটা shield-এ যায়, origin প্রতিটা অবজেক্ট একবার দেখে।
2. Request collapsing: একই অবজেক্টের একসাথে আসা হাজার MISS origin-এ একটা রিকোয়েস্ট হয়ে যায় (চ্যাপ্টার ৭)।
3. সফট পার্জ (নিচে): কপি মুছে না ফেলে “stale” চিহ্ন দেওয়া, যাতে origin ধীরে ধীরে রিফ্রেশ করে।
4. ছোট পরিসরে পার্জ: সব না, শুধু যা বদলেছে।

সফট পার্জ বনাম হার্ড পার্জ

	হার্ড পার্জ	সফট পার্জ
কী করে	কপি মুছে দেয়	কপি রাখে, কিন্তু মেয়াদোত্তীর্ণ (stale) চিহ্ন দেয়
পরের রিকোয়েস্ট	origin-এর জন্য অপেক্ষা	stale কপি পেতে পারে, পেছনে রিফ্রেশ হয় (stale-while-revalidate থাকলে)
origin ডাউন থাকলে	এরর	stale কপি দিতে পারে (stale-if-error থাকলে)
কখন	ভুল বা আইনি কারণে সরাতেই হবে এমন কন্টেন্ট	সাধারণ কন্টেন্ট আপডেট

সফট পার্জ সব CDN দেয় না; Fastly-র মতো কিছু ভেন্ডর দেয়। নিজের ভেন্ডরের ডকে “soft purge” খুঁজুন। গোপন বা আইনি কারণে সরাতে হবে এমন কিছু (ভুল করে প্রকাশ হওয়া ব্যক্তিগত তথ্য) সবসময় হার্ড পার্জ, আর সাথে origin থেকেও সরান।

stale-while-revalidate আর stale-if-error

এই দুইটা Cache-Control এক্সটেনশন (RFC 5861) পার্জ আর মেয়াদ শেষ হওয়াকে ইউজারের কাছে অদৃশ্য করে:

Cache-Control: public, s-maxage=300, stale-while-revalidate=60, stale-if-error=86400

• প্রথম ৩০০ সেকেন্ড: তাজা, সরাসরি ক্যাশ থেকে।
• পরের ৬০ সেকেন্ড: মেয়াদ শেষ, কিন্তু ক্যাশ পুরনো কপি সাথে সাথে দেয় আর পেছনে origin থেকে নতুন আনে। কোনো ইউজার অপেক্ষা করে না।
• origin এরর দিলে বা ডাউন থাকলে: এক দিন পর্যন্ত পুরনো কপি দেওয়া চলবে।

এটা পার্জের পরিপূরক: ছোট TTL দিয়ে কন্টেন্ট প্রায় তাজা থাকে, stale-while-revalidate দিয়ে ছোট TTL-এর খরচ (প্রতি কয়েক মিনিটে origin-এর জন্য অপেক্ষা) ইউজারকে দিতে হয় না, আর stale-if-error origin ডাউন থাকলে সাইট চালু রাখে। CDN ভেদে এই ডিরেক্টিভের সাপোর্ট আলাদা; কেউ কেউ নিজস্ব সেটিং দিয়ে একই কাজ করে। Cloudflare-এর UPDATING আর STALE স্ট্যাটাস (চ্যাপ্টার ৫) এই আচরণেরই চিহ্ন।

আসল সমাধান: পার্জের দরকারই না থাকা

ভার্সনড (fingerprinted) অ্যাসেট

বিল্ড টুল ফাইলের কন্টেন্ট থেকে হ্যাশ বানিয়ে নামে বসায়:

/assets/app.3f9a2c71.js
/assets/style.8b04d1e2.css
/img/logo.a91c0f.svg

কন্টেন্ট বদলালে নাম বদলায়। পুরনো নাম কখনো অন্য কন্টেন্ট পায় না, তাই চিরকাল ক্যাশ করা নিরাপদ:

Cache-Control: public, max-age=31536000, immutable

immutable (RFC 8246) ব্রাউজারকে বলে রিলোড করলেও revalidate করতে না, কারণ এই URL-এর কন্টেন্ট কখনো বদলাবে না। Vite, SvelteKit, webpack, esbuild — প্রায় সব আধুনিক বিল্ড টুল এটা ডিফল্টে করে।

HTML: ছোট TTL, বা revalidation

হ্যাশ করা অ্যাসেটের নাম থাকে HTML-এ, তাই HTML নিজে চিরকাল ক্যাশ করা যায় না। প্রচলিত ধরন:

# HTML: CDN may keep it briefly, browser always asks
Cache-Control: public, s-maxage=60, max-age=0, must-revalidate, stale-while-revalidate=30

# Hashed assets: forever
Cache-Control: public, max-age=31536000, immutable

ডিপ্লয়ের পর সর্বোচ্চ এক মিনিটের মধ্যে নতুন HTML সব জায়গায়, নতুন HTML নতুন অ্যাসেট নাম দেখায়, পুরনো অ্যাসেট ক্যাশে পড়ে থাকে কিন্তু ক্ষতি করে না। কোনো পার্জ লাগে না। চাইলে ডিপ্লয়ের পর শুধু HTML পাথগুলো পার্জ করতে পারেন যাতে এক মিনিটও অপেক্ষা না হয়।

API আর ডেটা পেজ

এখানে ভার্সনড URL সবসময় সম্ভব না। কৌশল: ছোট s-maxage + stale-while-revalidate, আর গুরুত্বপূর্ণ বদলে ট্যাগ পার্জ। সিদ্ধান্তের টেবিল:

কন্টেন্ট	কৌশল
JS, CSS, ফন্ট, বিল্ড করা ছবি	হ্যাশ নাম + এক বছর + immutable; কখনো পার্জ না
ইউজারের আপলোড করা ছবি	প্রতিটা আপলোড নতুন URL (আইডি বা হ্যাশ); পুরনো URL কখনো পুনর্ব্যবহার না
HTML	ছোট s-maxage, max-age=0, ডিপ্লয়ে ঐচ্ছিক HTML পার্জ
প্রোডাক্ট / আর্টিকেল পেজ	মাঝারি s-maxage + ট্যাগ + ডেটা বদলালে ট্যাগ পার্জ
পাবলিক API লিস্ট	ছোট s-maxage + stale-while-revalidate
প্রতি-ইউজার কিছু	শেয়ার্ড ক্যাশে না (private), পার্জের প্রশ্নই নেই

CI-তে ডিপ্লয়ের সাথে পার্জ

নিচের উদাহরণটা দেখানোর জন্য; এন্ডপয়েন্ট আর বডি আপনার ভেন্ডরের API ডক থেকে নিন:

#!/usr/bin/env bash
set -euo pipefail
: "${CDN_API_TOKEN:?missing}" "${CDN_ZONE_ID:?missing}"

# Purge only HTML entry points after a deploy; hashed assets never need it
curl -sS --fail-with-body -X POST \
  "https://api.cdn.example/zones/${CDN_ZONE_ID}/purge" \
  -H "Authorization: Bearer ${CDN_API_TOKEN}" \
  -H 'Content-Type: application/json' \
  --data '{"prefixes":["baytalhikma.org/","baytalhikma.org/books/"]}'

# Verify instead of trusting the 200
sleep 5
curl -sS -o /dev/null -D - https://baytalhikma.org/ | grep -iE '^(age|cf-cache-status|x-cache|cache-status):'

ভালো অভ্যাস:

• টোকেন শুধু পার্জ করার অনুমতি পাবে, পুরো অ্যাকাউন্টের না।
• ভেরিয়েবল না থাকলে স্ক্রিপ্ট সাথে সাথে থামবে (:?missing), চুপচাপ ভুল জোনে পার্জ করবে না।
• পার্জ ফেইল হলে ডিপ্লয় পাইপলাইন লাল হবে; “পরে দেখব” না।
• 200-এর পরে আসল রিকোয়েস্ট দিয়ে যাচাই।

যে ক্যাশ আপনি পার্জ করতে পারবেন না

CDN পার্জ শুধু CDN-এর কপি সরায়। বাকিগুলো:

ক্যাশ	নিয়ন্ত্রণ
ব্রাউজার ক্যাশ	max-age শেষ না হওয়া পর্যন্ত থাকবে। একমাত্র নিশ্চিত উপায় নতুন URL
Service Worker	নতুন SW ডিপ্লয় করে পুরনো ক্যাশ মোছা
কর্পোরেট বা ISP প্রক্সি	s-maxage/max-age মেনে চলে, পার্জ করা যায় না
অন্য CDN বা রিভার্স প্রক্সি সামনে থাকলে	তাদের নিজস্ব পার্জ

এজন্যই ব্রাউজারের জন্য max-age সাবধানে বেছে নিন: CDN-এর s-maxage লম্বা রাখা নিরাপদ (পার্জ করা যায়), ব্রাউজারের max-age লম্বা রাখা শুধু ভার্সনড URL-এ নিরাপদ।

Clear-Site-Data

Clear-Site-Data রেসপন্স হেডার ব্রাউজারকে বলতে পারে নিজের সাইটের ক্যাশ, cookie বা storage মুছে দিতে:

Clear-Site-Data: "cache"

এটা ইউজার যখন আপনার সাইটে কোনো রিকোয়েস্ট করে তখনই কাজ করে, আর ব্রাউজারভেদে সাপোর্ট আলাদা (বিশেষ করে "cache" ডিরেক্টিভ); তাই একে নির্ভরযোগ্য পার্জ ভাববেন না। লগআউট পেজে "cookies", "storage" এর জন্য বেশি কাজের। ব্যবহারের আগে MDN-এ বর্তমান ব্রাউজার সাপোর্ট দেখে নিন।

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

লক্ষণ	নিশ্চিত করার উপায়	সমাধান
পার্জের পরও পুরনো কন্টেন্ট (curl-এ)	curl -sS -o /dev/null -D - URL, age ছোট কিনা, HIT কিনা	হয়তো অন্য ক্যাশ কী (query, ডিভাইস, এনকোডিং); prefix বা tag পার্জ
curl-এ নতুন, ব্রাউজারে পুরনো	DevTools-এ Size কলামে “(disk cache)”	ব্রাউজার ক্যাশ; ভার্সনড URL, HTML-এ max-age=0
পার্জের পর সাথে সাথে আবার পুরনো	origin-এ সরাসরি --resolve দিয়ে দেখুন	origin নিজেই পুরনো দিচ্ছে (রেপ্লিকা ল্যাগ, অ্যাপ ক্যাশ), অথবা commit-এর আগে পার্জ
এক অঞ্চলে পুরনো, বাকি জায়গায় নতুন	ওই অঞ্চলের VPS থেকে টেস্ট	পার্জ এখনো পৌঁছায়নি বা ওই PoP মিস হয়েছে; আবার পার্জ, ভেন্ডর স্ট্যাটাস পেজ
পার্জের পর origin ডাউন	origin লোড গ্রাফ পার্জের সময় লাফিয়েছে কিনা	shield আর request collapsing চালু; সব পার্জ না করে ছোট পরিসরে
ডিপ্লয়ের পর কিছু ইউজারের পেজ ভাঙা, JS 404	ব্রাউজার কনসোলে পুরনো হ্যাশের অ্যাসেট 404	পুরনো অ্যাসেট কয়েকটা ডিপ্লয় রেখে দিন
CI-তে পার্জ মাঝে মাঝে ফেইল	API রেসপন্স 429	রেট লিমিট; URL তালিকা ছোট করুন, prefix/tag ব্যবহার করুন, রিট্রাই দিন
ট্যাগ পার্জে কিছুই হয় না	origin সরাসরি curl করে Cache-Tag/Surrogate-Key হেডার আছে কিনা	origin ট্যাগ পাঠাচ্ছে না, বা নাম ভুল, বা ট্যাগে স্পেস
?v=43 দিলেও পুরনো JS	CDN-এ query string উপেক্ষা হচ্ছে কিনা	ফাইলনেমে হ্যাশ

মূল শিক্ষা

1. পার্জ জরুরি অবস্থার টুল। স্বাভাবিক ডিপ্লয় এমনভাবে ডিজাইন করুন যাতে পার্জ লাগে না।
2. পার্জ API-র 200 মানে অনুরোধ পেয়েছে, কাজ শেষ না। আসল রিকোয়েস্ট দিয়ে যাচাই করুন।
3. URL পার্জ একটা ক্যাশ কী সরায়; ভ্যারিয়েন্টগুলো থেকে যেতে পারে।
4. ট্যাগ বা surrogate key দিয়ে পার্জ সবচেয়ে নিখুঁত। ডেটা বদলালে শুধু সেই ডেটা দেখানো পেজগুলো যায়।
5. ডেটাবেস commit-এর পরে পার্জ করুন, আর ফেইল হলে রিট্রাই করুন।
6. “সব পার্জ” origin-কে hit ratio-র অনুপাতে আঘাত করে। shield, collapsing আর সফট পার্জ ধাক্কা কমায়।
7. হ্যাশ করা অ্যাসেট + immutable, HTML-এ ছোট TTL — এটাই ডিফল্ট রেসিপি।
8. stale-while-revalidate আর stale-if-error ছোট TTL-কে সস্তা আর origin বিপর্যয়কে অদৃশ্য করে।
9. ব্রাউজারের ক্যাশ পার্জ করা যায় না। ব্রাউজারের জন্য লম্বা max-age শুধু ভার্সনড URL-এ।