Belajar System Design - Caching Strategies

#Pendahuluan

Setelah di episode 2 kita memahami scalability horizontal dan load balancing, pada episode ini kita masuk ke teknik yang paling sering membuat perbedaan dramatis dalam performa sistem: caching. Caching adalah prinsip sederhana: simpan hasil komputasi yang mahal di lokasi yang cepat diakses, sehingga request berikutnya tidak perlu mengulangi komputasi yang sama.

Cache adalah salah satu dari sedikit optimasi yang bisa mengurangi latency dari ratusan milidetik menjadi mikrodetik — penurunan 1000x. Tapi caching juga membawa masalah tersendiri: data stale, thundering herd, dan invalidation yang kompleks. Di episode ini kita bedah lapisan, pola, dan pitfalls caching secara lengkap.

#Lapisan Caching

Sistem modern punya beberapa lapisan caching yang bekerja bersama:

#Browser Cache

Browser menyimpan static assets (CSS, JS, gambar) secara lokal. Kontrol dilakukan lewat HTTP headers:

Cache-Control: max-age=31536000, immutable
ETag: "abc123"
Last-Modified: Wed, 16 Aug 2026 00:00:00 GMT

Cache-Control menentukan berapa lama resource di-cache. ETag dan Last-Modified memungkinkan conditional request (304 Not Modified).

#CDN Edge Cache

CDN (CloudFlare, CloudFront) menyimpan copy konten di server yang dekat secara geografis dengan pengguna.

• Static assets: CSS, JS, gambar → cache agresif (days/weeks).
• Dynamic content: API responses → cache singkat (seconds/minutes) atau tidak di-cache.
• Cache invalidation: purge via API atau versioned URLs (/style.v2.css).

#Application Cache (Redis/Memcached)

Lapisan caching di aplikasi, menyimpan data yang sering diakses dalam memori.

#Database Query Cache

Beberapa database punya built-in query cache:

• MySQL: query cache (deprecated di 8.0, gunakan ProxySQL atau application-level caching).
• PostgreSQL: tidak punya query cache bawaan — gunakan pgBouncer (connection pooling) + Redis.
• Database buffer pool: menyimpan page di memori untuk mengurangi disk I/O.

#Pola Caching

#Cache-Aside (Lazy Loading)

Pola paling umum: aplikasi mengecek cache dulu; jika miss, query database lalu simpan ke cache.

1. App check cache → HIT → return data
2. App check cache → MISS → query DB → write to cache → return data

Kelebihan: hanya cache data yang benar-benar diakses (lazy). Kekurangan: cold start (cache miss pertama selalu lambat), data bisa stale.

#Read-Through

Cache bertanggung jawab load data dari database saat miss — aplikasi hanya berinteraksi dengan cache.

Kelebihan: aplikasi lebih sederhana. Kekurangan: cache layer lebih kompleks.

#Write-Through

Setiap write ke database juga ditulis ke cache secara synchron.

Kelebihan: cache selalu konsisten dengan DB. Kekurangan: write latency meningkat (dua operasi).

#Write-Behind (Write-Back)

Write ke cache, lalu asynchronously flush ke database.

Kelebihan: write latency rendah (hanya ke cache). Kekurangan: risk data loss jika cache crash sebelum flush, complexity tinggi.

#Perbandingan Pola

#Cache Invalidation Strategy

"In the two hard things in computer science are cache invalidation and naming things." — Phil Karlton

#Time-To-Live (TTL)

Setiap entry cache punya waktu kadaluarsa. Setelah TTL habis, data dianggap stale dan dihapus.

SET user:1234 {"name": "Budi"} EX 3600
# Data expire dalam 3600 detik (1 jam)

Kelebihan: sederhana, otomatis. Kekurangan: data bisa stale sampai TTL habis; terlalu pendek = banyak cache miss.

#Event-Driven Invalidation

Hapus cache saat data berubah. Contoh: setelah update user di DB, hapus user:1234 dari cache.

Kelebihan: data lebih fresh. Kekurangan: butuh mekanisme publish-subscribe atau message queue untuk koordinasi.

#Masalah Umum Caching

#Thundering Herd

Saat cache expired secara bersamaan, banyak request langsung menghantam database secara serentak.

Cache expired → 1000 request MISS → 1000 query DB → DB overload

Solusi:

• Mutex/lock — hanya satu proses yang boleh reload cache, yang lain menunggu.
• Stale-while-revalidate — serve data stale sambil background refresh.
• Randomized TTL — tambahkan jitter ke TTL agar cache tidak expired bersamaan.

#Cache Stampede

Mirip thundering herd tapi pada data yang sama yang belum pernah di-cache (cold start).

Solusi: pre-warming cache saat deployment, atau gunakan request coalescing (gabungkan beberapa request yang sama menjadi satu query DB).

#Hot Key

Satu key di-cache yang diakses sangat sering — menjadi bottleneck di satu Redis/Memcached node.

Solusi: local cache di aplikasi (L1 cache), replication key ke beberapa node, atau client-side caching.

#Cold Start

Saat aplikasi baru deploy atau restart, cache masih kosong. Semua request pertama kali menghantam database.

Solusi: cache warming script yang pre-load data populer ke cache saat startup.

#Penutup

Inti yang harus dibawa pulang:

• Lapisan caching: browser → CDN → application (Redis) → database. Setiap lapisan punya peran.
• Pola utama: cache-aside (paling umum), read-through, write-through, write-behind.
• Invalidasi: TTL sederhana tapi bisa stale; event-driven lebih fresh tapi kompleks.
• Pitfalls: thundering herd, cache stampede, hot key, cold start — semua punya solusi yang terbukti.

Di episode 4 selanjutnya kita akan membahas database fundamentals untuk scale — SQL vs NoSQL, replikasi leader-follower, dan partitioning/sharding. Caching membantu performa read, tapi database adalah fondasi data yang menentukan arsitektur seluruh sistem!