Awalnya cuma nganggep CDN itu sekadar “perantara” tambahan antara user dan server. Kalau server udah bisa serve file langsung, buat apa nambah satu layer lagi?

Setelah nyobain efek CDN sendiri, oh... ternyata begini toh gunanya CDN. 💀

Dan yang paling bikin kaget, buat static assets sederhana seperti image, efeknya bisa lumayan pol buat ngurangin beban server.

Namanya juga rookie mistake kan, yang pengen nambah skill dari mobile engineer ke full-stack kan ya gitu, ternyata masih banyak banget yang harus dipelajari.

RustFS / S3

Sebelumnya aku udah pernah bahas S3 Object storage pakai RustFS di sini, https://aramadani.my.id/blog/6-hal-yang-aku-pelajari-waktu-iseng-bikin-photobooth.

Jadi setup awalnya kurang lebih gini:

User
  ↓
RustFS / S3

Semua image langsung diambil dari origin.

Awalnya ya fine fine aja. Request masuk, RustFS serve file, selesai.

Terus sempet kepikiran gini:

Kalau image yang sama diminta 100 kali, kenapa origin harus kerja 100 kali juga?

Misalnya ada:

/ABC.jpg

User A request.

Server kirim 500 KB.

Lalu User B request file yang sama.

Server kirim lagi dong 500 KB.

User C request lagi.

Server kirim lagi 500 KB.

Dan seterusnya.

Kalau traffic makin besar, server bakal terus-terusan kerja hal yang sama berulang-ulang.

Nah, di sinilah CDN mulai terasa useful.

Cloudflare

Akhirnya aku setup kira-kira begini:

                    ┌──────────────┐
                    │    User      │
                    └──────┬───────┘
                           │
                           ▼
                    ┌──────────────┐
                    │  Cloudflare  │
                    │     CDN      │
                    └──────┬───────┘
                           │
                      cache miss
                           │
                           ▼
                    ┌──────────────┐
                    │ Server / S3  │
                    │    Origin    │
                    └──────────────┘

Sekarang Cloudflare ada di depan sebelum hit server origin.

Request pertama untuk sebuah image mungkin begini:

User
 ↓
Cloudflare
 ↓
"Eh, aku belum punya file ini."
 ↓
Server / S3
 ↓
Image
 ↓
Cloudflare cache
 ↓
User

Request berikutnya?

User
 ↓
Cloudflare
 ↓
"Relax bro, aku punya."
 ↓
Cache
 ↓
User

Server bahkan nggak tersentuh lagi jika cache di-hit.

Dan ternyata efeknya lumayan gokil cuy, aku cek statistik 24 jam terakhir

Hasilnya kurang lebih:

Metric Total Cached Uncached

Requests | 2.81K | 2.29K | 516
Bandwidth | 346.82 MB | 261.98 MB | 84.84 MB

Kalau dihitung:

Request

2,290 / 2,810 ≈ 81.5%

Jadi sekitar 81.5% request sudah dilayani dari cache.

Bandwidth

261.98 / 346.82 ≈ 75.5%

Sekitar 75.5% bandwidth sudah dilayani dari cache.

Dan ini honestly cukup menarik sih bagiku.

Karena artinya dari sekitar 347 MB total bandwidth yang dikirim ke user, 262 MB-nya berasal dari Cloudflare cache, bukan dari server lagi.

347 MB
│
├── 262 MB → Cloudflare cache
│
└── 85 MB → origin

"Tapi bukannya CDN cuma mempercepat?"

Nah, ini salah satu misconception baru buatku juga.

CDN emang bisa bikin delivery lebih dekat ke user karena punya edge locations di berbagai tempat.

Tapi menurutku, manfaat yang paling terasa justru:

origin offloading.

Bayangkan ada satu image:

image.jpg = 5 MB

Tanpa cache:

100 users × 5 MB
= 500 MB dari origin

Dengan cache:

First request:
Server → Cloudflare = 5 MB

99 request berikutnya:
Cloudflare cache → users

Origin mungkin cuma perlu mengeluarkan sekitar:

5 MB

daripada:

500 MB

Pastinya dalam real-world behavior bisa lebih kompleks karena ada multiple edge locations, cache expiration, revalidation, cache key, dan lain-lain.

Tapi ya, konsep yang baru aku paham sih, dasarnya sesederhana itu.

Apalagi kalau URL asset-nya immutable

Ini bagian yang menurutku penting banget.

Misalnya URL imagenya:

/books/01M360FV1S4VFTBJBX6ND2VEAQ.jpg

Dan setelah file dibuat, isinya nggak akan pernah berubah.

Kalau mau update image, tinggal generate object baru dengan ID baru aja.

Pattern gini sangat cocok pakai CDN:

/book/ABC.jpg → immutable
/book/DEF.jpg → immutable
/book/GHI.jpg → immutable

Karena Cloudflare bisa menyimpan object tersebut untuk waktu yang lama tanpa harus khawatir:

"Eh, file ini ternyata berubah."

Kalau file memang immutable, caching agresif jadi jauh lebih masuk akal.

Jadi sekarang aku malah mikir...

Dulu:

"User belum ada, kasih CDN kayaknya overkill deh."

Sekarang:

"Kenapa dari awal nggak aku pasang? Toh gratis, itung-itung belajar arsitektur"

Apalagi kalau aplikasinya punya banyak static assets.

Architecture sederhana seperti:

App
 ↓
CDN
 ↓
Object Storage

ternyata bisa memberikan beberapa benefit sekaligus:

Origin bandwidth lebih rendah
Origin request lebih sedikit
Asset bisa diserve dari edge
Latency bisa lebih rendah
Traffic spike lebih mudah ditangani
Origin infrastructure lebih ringan

Dan yang paling lucu:

Untuk skala kecil, benefit-nya bisa didapat tanpa harus langsung keluar duit banyak.

Tapi jangan sampai CDN dijadikan magic wand

Ini juga perlu diluruskan.

CDN bukan berarti semua problem networking otomatis selesai.

Kalau origin lambat:

Cloudflare MISS
      ↓
Origin lambat
      ↓
User tetap nunggu

Kalau cache policy salah, CDN juga bisa kurang berguna.

Kalau setiap URL selalu berbeda:

/image?id=1
/image?id=2
/image?id=3
...

dan semuanya cuma dipakai sekali, cache hit rate bisa tetap rendah.

Kalau asset terlalu dynamic, CDN juga bukan solusi utama.

Jadi prinsipnya bukan:

"Pasang CDN = website auto cepat."

Lebih tepat:

"Untuk data yang cocok di-cache, CDN bisa menghilangkan banyak pekerjaan redundant dari origin."

And that's the part di mana aku nemu 'ohh moment'.

Conclusion

Setelah lihat sendiri angka:

2.81K requests
81.5% cached requests

346.82 MB bandwidth
75.5% cached bandwidth

aku akhirnya ngerti kenapa CDN itu bukan sekadar "server tambahan".

It's basically a giant distributed cache sitting between your users and your infrastructure.

Dan untuk static assets yang sering diakses berulang-ulang?

It just makes sense.

Dulu aku:

"Ah, paling cuma biar lebih cepat."