ชั้นของ cache ใน web stack ทั่วไปมีอะไรบ้าง?

Question

IT Interview Practice · Accepted Answer

คำขอหนึ่งผ่าน **ชั้นของ cache หลายชั้น** แต่ละชั้นที่ใกล้ผู้ใช้กว่าเสิร์ฟได้เร็วกว่าแต่เก็บข้อมูลได้น้อยกว่า แนวคิดคือตอบให้ไกลออกไปที่สุด (ใกล้ client ที่สุด) เท่าที่จะทำได้ และตกลงไปถึง origin ก็ต่อเมื่อไม่มีชั้นใดด้านบนเสิร์ฟ response ได้

## ชั้นต่าง ๆ จากนอกเข้าใน

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **Browser cache** — เก็บ static asset (JS, CSS, รูปภาพ) และ response ที่แคชได้บนอุปกรณ์ของผู้ใช้ TTL ควบคุมโดย `Cache-Control`/`ETag` asset มักได้ TTL ยาว (เป็นวันถึงปี) ด้วยชื่อไฟล์ที่ใส่ hash
- **CDN** (CloudFront, Cloudflare) — แคช content แบบ static และบางครั้ง dynamic ที่ edge node ใกล้ผู้ใช้ TTL ตั้งแต่นาที (HTML) ถึงหนึ่งปี (asset ที่ไม่เปลี่ยนแปลง)
- **Reverse proxy** (Varnish, nginx) — แคชหน้าเต็มหรือ fragment ไว้หน้าแอป TTL ระดับวินาทีถึงนาทีสำหรับหน้ายอดนิยม รองรับการ purge เมื่อมีการเปลี่ยนแปลง
- **Application / object cache** (Redis, Memcached) — แคชผลลัพธ์ที่คำนวณแล้ว, ผลการ query DB, session, fragment ที่ render แล้ว TTL ระดับวินาทีถึงชั่วโมง บวกกับการ invalidate แบบชัดเจน
- **OPcache** — แคช **PHP bytecode ที่ compile แล้ว** ในหน่วยความจำ เพื่อให้ script ไม่ถูก re-parse ทุกคำขอ คงอยู่อย่างถาวรจนกว่าจะ deploy code
- **DB query / buffer cache** — ฐานข้อมูลเก็บ page ยอดนิยมและ (ในบาง engine) ผลการ query ไว้ในหน่วยความจำ เพื่อหลีกเลี่ยงการอ่านดิสก์

## วิธีคิดเกี่ยวกับชั้นเหล่านี้

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

แต่ละชั้นแลกระหว่าง **ความสดใหม่กับความเร็ว** ชั้นนอกเร็วที่สุดแต่มีแนวโน้มจะ stale มากที่สุด ดังนั้นให้ตั้ง TTL ยาว + content hashing กับสิ่งที่ static จริง ๆ และ TTL สั้น + invalidation กับสิ่งที่ dynamic

## ทำไมจึงสำคัญ

การลด latency และโหลดใน web stack ส่วนใหญ่มาจากการแคชที่ชั้นที่ถูกต้อง การรู้ว่าแต่ละชั้นเก็บอะไรและ TTL ทั่วไปของมัน ทำให้คุณวาง cache ตรงที่มันช่วยได้จริง หลีกเลี่ยงการเสิร์ฟข้อมูล stale และให้เหตุผลได้ว่าทำไมการเปลี่ยนแปลงถึงยังไม่ปรากฏ (ชั้นไหนยังเสิร์ฟสำเนาเก่าอยู่)

ชั้นต่าง ๆ จากนอกเข้าใน

วิธีคิดเกี่ยวกับชั้นเหล่านี้

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง