Wawancara Desain Sistem: Bagaimana Anda Mendesain Content Delivery Network Global?

Masalah dan Skenario yang Berlaku

Desain content delivery network pull multi-tenant dengan 50 points of presence (PoP). Pada jam sibuk, sistem menerima 2 juta permintaan GET dan HEAD per detik, dan rata-rata respons GET yang dapat di-cache adalah 256 KiB. Origin pelanggan dapat dengan aman menerima total 20.000 fetch per detik. CDN melayani aset dengan content-hash, gambar, segmen video, dan dokumen mutable pada URL yang stabil.

Targetnya adalah p99 time to first byte di bawah 50 milidetik untuk respons yang di-cache dalam kondisi normal, ketersediaan permintaan 99,99%, dan penerapan setiap purge pada 99% PoP yang sehat dalam waktu 60 detik. Propagasi lengkap dan PoP yang tertinggal harus tetap dapat dipantau (observable). Nilai-nilai ini adalah asumsi wawancara, bukan klaim tentang penyedia mana pun.

Desain ini berlaku ketika pengguna terdistribusi secara geografis, jarak ke origin mendominasi latensi, objek yang berulang dapat digunakan kembali, dan bandwidth atau komputasi origin terbatas. Layanan internal privat dengan satu wilayah dan sedikit penggunaan ulang mungkin lebih membutuhkan regional reverse proxy. Ruang lingkup wawancara ini membangun mekanisme inti CDN; membeli managed CDN tetap menjadi pilihan produksi yang valid setelah persyaratan, batas keamanan, biaya operasional, dan model kegagalan penyedia dibandingkan.

Apa yang Dievaluasi oleh Pewawancara

Sinyal pertama adalah apakah kandidat memisahkan control plane dari data plane. Onboarding tenant, konfigurasi origin, sertifikat, aturan cache, dan perintah purge memerlukan alur kerja manajemen yang tahan lama (durable). Melayani permintaan harus tetap berlanjut dari konfigurasi terakhir yang diketahui baik (last-known-good) ketika jalur manajemen tersebut tidak tersedia.

Sinyal kedua adalah kebenaran batas cache. Cache key yang menghilangkan dimensi representasi dapat membocorkan atau merusak respons lintas bahasa, pengkodean, perangkat, atau tenant. Key yang menyertakan setiap cookie dan header akan memfragmentasi cache hingga hampir setiap permintaan mengalami miss. Jawaban harus menentukan permintaan mana yang memenuhi syarat, dimensi mana yang membedakan representasi, dan respons privat mana yang melewati shared storage.

Sinyal ketiga adalah perlindungan origin. Dengan 50 PoP, satu objek yang baru populer dapat menghasilkan 50 cold fill simultan bahkan sebelum adanya percobaan ulang (retry). Request coalescing di setiap tingkat, regional shield, konkurensi origin yang dibatasi, dan anggaran percobaan ulang menyelesaikan berbagai bagian dari jalur tersebut. Tidak boleh ada mode kegagalan yang secara diam-diam mengubah 2 juta permintaan edge per detik menjadi lalu lintas origin.

Sinyal keempat adalah kebenaran invalidasi. Purge yang hanya menghapus byte saat ini dapat beradu (race) dengan proses fill yang lebih lama dan menyebabkan konten usang (stale) muncul kembali. Jawaban yang kuat menggunakan ordered generation atau tombstone, membuat pengiriman bersifat idempoten, dan mengukur SLO propagasi umum serta long tail.

Terakhir, kandidat harus mengukur throughput, menyatakan kontrak konsistensi dan keusangan (staleness) yang eksplisit, mencakup batasan kegagalan dan keamanan, serta mengusulkan pengujian yang membuktikan perilaku yang terlihat oleh pengguna. Daftar produk vendor tidak memberikan bukti tersebut.

Pertanyaan Klarifikasi Sebelum Menjawab

• Apakah CDN memiliki objek sumber? Tidak. Ini adalah pull CDN; origin pelanggan tetap menjadi otoritatif.
• Metode mana yang dapat di-cache? Mulai dengan GET dan HEAD. Metode yang tidak aman (unsafe) langsung diteruskan dan tidak pernah dimasukkan ke dalam shared cache oleh baseline ini.
• Konten mana yang bersifat privat? Permintaan dengan otorisasi atau cookie khusus pengguna melewati shared caching kecuali jika tenant menyediakan kebijakan partisi yang eksplisit dan telah ditinjau.
• Seberapa segar konten mutable harus disajikan? Setiap rute menentukan TTL dan jendela stale yang dibatasi. Purge ditargetkan untuk perubahan mendesak; ini bukan pengganti pemeriksaan otorisasi atau pencabutan.
• Apakah setiap parameter kueri bermakna? Tidak. Tenant memasukkan parameter yang mengubah representasi ke dalam allowlist dan dapat menghapus parameter pelacakan yang diketahui setelah kanonikalisasi.
• Apakah byte range diperlukan? Ya untuk media besar. Key dan metadata harus membedakan objek lengkap dari range yang divalidasi, dan origin harus menyediakan validator stabil atau URL berversi.
• Bagaimana PoP terdekat dipilih? DNS dan/atau anycast merutekan pengguna ke PoP yang dapat dijangkau. Pemilihan jalur BGP bukan jaminan kedekatan geografis, sehingga kesehatan dan latensi yang terukur tetap diperlukan.
• Apa yang terjadi ketika control plane gagal? Lalu lintas yang ada terus berjalan dengan konfigurasi last-known-good yang ditandatangani; perubahan yang tidak aman fail-closed dan diantrekan untuk diterapkan nanti.
• Bisakah data stale disajikan selama pemadaman (outage) origin? Hanya untuk rute dengan izin stale-if-error eksplisit dan batas usia maksimum tertentu.
• Apa arti dari penyelesaian purge? Target 60 detik mencakup 99% PoP yang sehat; sistem mencatat setiap acknowledgment, PoP yang tertinggal, percobaan ulang, dan hasil probe secara terpisah.

Kerangka Jawaban 30 Detik

“Saya memisahkan control plane dan data plane. DNS dan anycast mengarahkan ke PoP yang sehat; edge memilih konfigurasi tenant yang ditandatangani, mengkanonikalisasi key yang ada di allowlist, dan memeriksa RAM lalu SSD. Permintaan yang miss digabungkan (coalesce) di edge dan regional shield sebelum mengambil data ke origin sesuai anggaran; penyajian stale mengikuti batas eksplisit. Aset immutable menggunakan URL berversi. URL mutable menggunakan ordered purge generation dan tombstone, dan proses fill membandingkan generation sebelum publikasi sehingga byte lama tidak dapat kembali. Saya memverifikasi request dan byte hit rate, beban origin, p99 hit TTFB, usia stale, lag purge, dan perilaku saat terjadi pemadaman.”

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Kuantifikasi lalu lintas dan anggaran origin

Menggunakan ukuran rata-rata GET sebagai batas perencanaan untuk beban puncak, bandwidth respons sebelum overhead protokol adalah:

2,000,000 requests/s × 256 KiB × 8 = 4.19 Tb/s

Jika puncak tersebut dipertahankan selama sehari, itu akan mewakili sekitar 45,3 PB byte respons edge. Di 50 PoP, rata-rata sederhananya adalah 40.000 permintaan/detik dan 10,5 GB/detik per PoP, tetapi lalu lintas sebenarnya miring (skewed) secara geografis dan temporal. Oleh karena itu, perencanaan kapasitas menggunakan puncak per-PoP yang terukur, headroom, persentil ukuran objek, dan redistribusi kegagalan; rata-rata hanyalah baseline.

Batas origin adalah 1% dari puncak permintaan edge:

20,000 / 2,000,000 = 1%

Itu tidak berarti target hit-rate edge saja adalah 99%. Shield hit, rute yang tidak dapat di-cache, proses fill, revalidasi, dan percobaan ulang semuanya menghabiskan anggaran origin yang sama. Penjadwal (scheduler) yang menghadap origin memerlukan batas konkurensi dan laju permintaan per-tenant, per-origin, dan global.

Langkah 2: Pisahkan control plane dan data plane

Control plane menyimpan tenant, domain, identitas origin, sertifikat, kebijakan cache, aturan kanonikalisasi, batas stale, key URL bertanda tangan, dan versi konfigurasi. Perubahan yang divalidasi di-commit secara tahan lama, dikompilasi ke dalam snapshot bertanda tangan, dan didistribusikan melalui versioned stream. PoP mengonfirmasi (acknowledge) versi yang diterapkan. Private key sertifikat menggunakan batas manajemen rahasia dan key khusus dan berada di luar penyimpanan konfigurasi biasa.

Data plane menangani TLS, pencarian tenant, penegakan kebijakan, normalisasi permintaan, caching, akses origin, dan log. Data plane tidak pernah memanggil database control plane secara sinkron saat terjadi cache hit. PoP mempertahankan snapshot bertanda tangan last-known-good selama pemadaman control plane. Konfigurasi stale memiliki masa pakai terbatas; sertifikat yang kedaluwarsa, tenant yang dicabut, dan kebijakan keamanan yang ambigu akan fail-closed setelah masa pakai tersebut berakhir.

Langkah 3: Rute lalu lintas dan isolasi tenant

DNS dapat mengembalikan nama regional atau alamat anycast; jaringan anycast dapat mengumumkan alamat yang sama dari beberapa PoP. Perutean memilih jalur jaringan yang dapat dijangkau, kemudian kesehatan layanan menghapus PoP yang buruk dan mengalihkannya (drain) ke lokasi lain. Desain ini melacak perubahan rute, beban failover, dan latensi karena “terdekat” adalah hasil yang diamati, bukan jaminan BGP.

Di edge, SNI dan Host yang dinormalisasi dipetakan ke satu tenant sebelum pencarian cache dilakukan. Tenant ID adalah komponen pertama implisit dari setiap namespace cache. Origin hanya menerima lalu lintas CDN yang terautentikasi melalui mTLS, permintaan bertanda tangan, konektivitas privat, atau rotating secret, dan tidak boleh dapat dilewati secara publik. Alamat origin dan pengalihan (redirect) dimasukkan ke dalam allowlist untuk mencegah SSRF.

Langkah 4: Tentukan kelayakan cache dan key

Baseline hanya mengizinkan respons GET dan HEAD yang sukses ketika kebijakan rute dan field HTTP mengizinkan penggunaan bersama. private, no-store, otorisasi, cookie khusus pengguna, Set-Cookie, dan nilai Vary yang tidak didukung biasanya melewati penyimpanan. Respons negatif hanya boleh di-cache untuk TTL singkat dan spesifik terhadap status agar kegagalan sementara tidak menjadi pemadaman yang lama.

Key konseptualnya adalah:

tenant_id | canonical_scheme_host | normalized_path | selected_query |
encoding_variant | approved_vary_dimensions | object_generation

Kanonikalisasi terjadi sekali sebelum kebijakan, pencarian, logging, fill, dan purge. Hanya parameter kueri dan header yang benar-benar mengubah byte yang dimasukkan ke dalam key. Menambahkan Accept-Language sudah benar jika origin bervariasi berdasarkan bahasa; menambahkan sembarang cookie atau User-Agent dapat meledakkan kardinalitas. Vary dari suatu respons harus sesuai dengan dimensi yang diizinkan rute, atau respons tersebut akan melewati caching.

Kesegaran mengikuti kebijakan tenant dan semantik HTTP: entri segar dikembalikan secara langsung; entri stale divalidasi ulang dengan ETag atau Last-Modified; stale-while-revalidate dan stale-if-error hanya digunakan dalam batas eksplisit. no-cache berarti validasi ulang sebelum digunakan kembali, sedangkan no-store berarti jangan disimpan. Kebijakan cache tidak boleh melemahkan arahan privasi origin yang lebih ketat.

Langkah 5: Bangun jalur fill RAM, SSD, shield, dan origin

Setiap PoP menyimpan metadata panas dan objek kecil di RAM serta cache SSD yang lebih besar dengan kontrol penerimaan (admission control). Penerimaan dan penggusuran (eviction) mempertimbangkan laju permintaan, ukuran byte, kebaruan (recency), dan biaya fetch sehingga satu pemindaian objek dingin yang besar tidak dapat menggusur working set yang berguna. Origin tetap otoritatif; kehilangan cache edge adalah peristiwa performa, bukan kehilangan data.

Saat terjadi miss, tabel singleflight menggabungkan (coalesce) pemanggil untuk key yang sama persis. Satu pemanggil meminta ke regional shield; pengikut menunggu untuk waktu terbatas atau menggunakan entri stale yang diizinkan. Shield mengulangi pencarian dan penggabungan di banyak PoP. Hanya fill yang terpilih yang masuk ke penjadwal origin. Batas penggabungan kedua ini mencegah satu objek dingin membuat fetch origin independen per PoP.

Setiap fill memiliki batas waktu (deadline), ukuran maksimum, validasi tipe konten, checksum, anggaran byte tenant, dan anggaran percobaan ulang. Percobaan ulang menggunakan exponential backoff dan jitter tetapi tetap menghabiskan anggaran origin. Hedging dibatasi pada pembacaan idempoten dan tidak boleh menggandakan pekerjaan origin tanpa batasan yang ketat. Objek besar di-stream ke klien sambil menulis entri cache sementara; entri tersebut hanya terlihat setelah panjang yang diharapkan, validator, dan checksum selesai.

Langkah 6: Amankan race condition antara purge dan fill

Nama file berbasis alamat konten (content-addressed) adalah default untuk aset immutable: memublikasikan byte baru akan membuat URL baru, dan URL lama dapat kedaluwarsa secara alami. URL mutable memerlukan API purge eksplisit yang mendukung objek persis, awalan (prefix) atau tag yang disetujui, dan purge darurat cakupan-tenant. Purge massal dibatasi lajunya (rate-limited) dan memerlukan otorisasi yang lebih kuat karena dapat menciptakan badai miss global.

Koordinator purge melakukan commit {tenant, selector, generation, issued_at} ke log berurutan yang tahan lama sebelum memberikan konfirmasi (acknowledgment). PoP menerapkan peristiwa tersebut secara idempoten, memajukan batas generation minimum pemilih, menghapus byte yang cocok, dan mempertahankan tombstone cukup lama untuk mencakup fill lama dan peristiwa yang tertunda. PoP melaporkan generation yang telah diterapkan. Fan-out hierarkis, percobaan ulang, dan relay regional mencegah satu PoP yang lambat memblokir jalur umum.

Sebelum memublikasikan objek yang di-fill, cache membandingkan generation yang dicatat pada awal fetch dengan generation minimum saat ini. Jika purge bertambah maju selama proses fetch, byte tersebut dibuang atau di-fetch ulang di bawah generation yang baru. Perbandingan ini mencegah respons lama yang tiba setelah penghapusan membangkitkan kembali konten yang usang. Aturan yang sama berlaku di lapisan edge dan shield.

API melaporkan status diterima, 99%-terpropagasi, dan selesai-atau-kedaluwarsa secara terpisah. Probe sintetis meminta key yang di-purge dari berbagai wilayah dan memvalidasi header versi atau content hash. Pencabutan keamanan tetap menjadi bagian dari pemeriksaan online otoritatif atau masa pakai token yang dibatasi secara terpisah; SLO cache-purge 60 detik bukanlah pencabutan instan.

Langkah 7: Tangani kelebihan beban dan kegagalan secara eksplisit

• Kegagalan PoP: tarik atau hentikan pengumuman rute, alihkan ke PoP yang sehat, dan cadangkan kapasitas untuk lalu lintas yang didistribusikan ulang.
• Kehilangan SSD: bangun kembali secara bertahap melalui kontrol penerimaan; jangan menghangatkan setiap objek sekaligus atau melewati shield.
• Kegagalan Shield: pilih shield sekunder; jika fallback langsung ke origin diizinkan, pertahankan anggaran origin yang sama.
• Origin timeout atau 5xx: sajikan konten stale yang dibatasi hanya jika kebijakan mengizinkan; jika tidak, kembalikan kesalahan eksplisit dan hindari amplifikasi percobaan ulang.
• Pemadaman control plane: tetap melayani dari konfigurasi bertanda tangan last-known-good; antrekan perubahan yang aman dan tolak mutasi sensitif keamanan yang tidak dapat diverifikasi.
• Keterlambatan stream purge: coba lagi secara idempoten, ekspos PoP yang tertinggal, dan lewati atau validasi ulang key yang terpengaruh ketika generation kritis diketahui tetapi byte tidak dapat dipercaya.
• Lonjakan objek panas: gabungkan fill, replikasikan objek di seluruh proses cache, lindungi satu proses dari saturasi NIC atau lock, dan batasi laju tenant yang melakukan penyalahgunaan.

Langkah 8: Amankan dan verifikasi sistem secara menyeluruh

Terminasi TLS dengan sertifikat cakupan-tenant dan lindungi identitas origin. Terapkan batas ukuran permintaan, jumlah header, jumlah range, dan ukuran respons. Normalisasikan jalur ambigu dan field HTTP sekali untuk mencegah request smuggling dan ketidakcocokan cache-key. Partisi kuota, key, log, hak purge, dan namespace cache berdasarkan tenant. URL atau cookie bertanda tangan diverifikasi sebelum pencarian, dan kebijakannya tidak boleh secara tidak sengaja mengubah respons privat menjadi objek publik.

Pantau request hit rate dan byte hit rate secara terpisah, hit TTFB, miss latency, shield hit rate, QPS dan bandwidth origin, follower yang digabungkan, kardinalitas cache-key, byte yang digusur, usia stale, lag purge berdasarkan PoP, versi konfigurasi, tingkat kesalahan, dan beban failover. Log mencatat privacy-safe key digest, tenant, PoP, jenis hasil, usia, generation, tier hulu, dan trace ID.

Validasi mencakup cold start objek panas dari seluruh 50 PoP, purge yang beradu dengan proses fill yang sengaja dibuat lambat, peristiwa purge duplikat dan di luar urutan, Vary yang teracuni, bypass otorisasi dan cookie, fill range parsial, restart SSD, kehilangan shield, throttling origin, penarikan PoP, dan pemadaman control plane. Pemeriksaan penerimaan mencakup p99 TTFB cache di bawah 50 milidetik dalam kondisi normal, ketersediaan permintaan 99,99%, fetch origin sebesar atau di bawah 20.000 per detik, dan 99% PoP sehat menerapkan purge dalam 60 detik tanpa kebangkitan konten stale.

Contoh Jawaban Berkualitas Tinggi

“Saya akan mulai dengan batas kapasitas. Dua juta permintaan per detik pada 256 KiB adalah sekitar 4,19 Tb/s lalu lintas respons puncak. Origin hanya dapat menerima 1% dari volume permintaan edge, sehingga perlindungan origin adalah invarian mutlak, bukan pengoptimalan opsional.

Saya memisahkan control plane yang tahan lama dari data plane yang melayani permintaan. Konfigurasi tenant, sertifikat, identitas origin, aturan cache, dan purge diberi versi dan diaudit. PoP melayani dengan konfigurasi last-known-good yang ditandatangani alih-alih mengueri database tersebut pada setiap permintaan. DNS dan anycast merutekan pengguna ke PoP yang sehat; SNI dan Host mengidentifikasi tenant sebelum pencarian cache ber-namespace.

Key berisi tenant, URL kanonikal, hanya dimensi kueri dan header yang mengubah representasi, serta generation. Respons privat, terotorisasi, no-store, dan tidak aman melewati shared cache. Cache hit berasal dari RAM atau SSD. Cache miss digabungkan di edge, dikirim ke regional shield, digabungkan kembali, dan diterima melalui anggaran per-origin dan global. Jalur fresh, revalidated, dan bounded-stale dipisahkan dengan jelas.

Aset immutable menggunakan URL berversi. Purge URL mutable pertama-tama melakukan commit generation yang meningkat ke log yang tahan lama. Setiap tier menyimpan generation minimum yang diizinkan dan tombstone. Proses fill memeriksa generation tersebut sebelum publikasi, sehingga byte yang diambil sebelum purge tidak dapat tiba setelahnya dan memulihkan konten stale. Saya mengekspos status 99%-terpropagasi dan selesai alih-alih menyembunyikan PoP yang tertinggal.

Saya akan membuktikan desain ini dengan request hit rate dan byte hit rate, QPS origin, p99 hit TTFB, usia stale, lag purge, dan versi konfigurasi. Kemudian saya akan menguji skenario cold miss objek panas, purge/fill race, kegagalan PoP dan shield, throttling origin, peristiwa purge di luar urutan, cache-key poisoning, dan pemadaman control plane, dengan mempertahankan empat SLO yang dinyatakan sebagai kriteria penerimaan.”

Kesalahan Umum

• Menyebut PoP terdekat secara geografis dijamin → BGP memilih jalur jaringan, bukan jarak garis lurus → ukur latensi dan kesehatan, serta desain penarikan rute dan failover.
• Menyertakan setiap header permintaan di dalam key → kardinalitas meledak dan sebagian besar lalu lintas menjadi miss → masukkan hanya dimensi yang mengubah representasi ke allowlist dan tolak Vary yang tidak didukung.
• Menghilangkan identitas tenant dari namespace → URL yang identik dapat melintasi batas tenant → turunkan tenant sebelum pencarian dan jadikan sebagai prefiks key implisit.
• Menghapus byte pada saat purge tanpa generation → fill lama yang sedang berjalan dapat memublikasikannya kembali → majukan tombstone dan bandingkan generation sebelum memasukkan ke cache.
• Hanya menambahkan lock di edge → 50 PoP masih dapat mengeluarkan 50 fill origin → gabungkan kembali di shield dan pertahankan anggaran di seluruh origin.
• Mencoba ulang setiap permintaan origin yang gagal → percobaan ulang memperparah pemadaman → gunakan batas waktu, anggaran terbatas, jitter, serta perilaku stale atau kesalahan khusus rute.
• Menggunakan purge untuk pencabutan keamanan instan → propagasi memiliki jeda ekor (tail) yang terukur → gunakan pemeriksaan otoritatif atau masa pakai kredensial terbatas untuk keputusan keamanan.
• Hanya melaporkan request hit rate → banyak hit kecil dapat menyembunyikan miss besar yang mahal → lacak juga byte hit rate, bandwidth origin, distribusi ukuran, dan biaya fetch.

Pembahasan Mendalam Lanjutan

Lanjutan 1: Bagaimana Anda mendukung objek video besar dan permintaan range?

Pilih URL segmen immutable dan cache segmen lengkap jika memungkinkan secara praktis. Validasi Content-Range, panjang objek, validator, dan generation sebelum menggabungkan range. Batasi jumlah range dan amplifikasi, dan jangan pernah membiarkan dua representasi berbagi partial-object key. Untuk objek yang sangat besar, sejajarkan chunk ke grid terkontrol sehingga permintaan yang tumpang tindih dapat menggunakan kembali byte tanpa membuat fragmen arbitrer.

Lanjutan 2: Bagaimana Anda mencegah serangan cache-key poisoning?

Kanonikalisasikan URL dan field HTTP sekali, tolak pengkodean yang ambigu, dan sertakan setiap input yang disetujui yang mengubah byte origin. Jangan meneruskan header tanpa key yang digunakan origin untuk pemilihan representasi. Uji header yang berkonflik, field duplikat, pengkodean jalur, urutan kueri, dan normalisasi host di edge dan origin sehingga kedua sisi menginterpretasikan permintaan secara identik.

Lanjutan 3: Haruskah HTML yang dipersonalisasi di-cache di edge?

Hanya dengan kontrak produk dan keamanan yang eksplisit. Opsi yang lebih aman adalah men-cache shell publik dan mengambil data privat secara terpisah. Jika HTML lengkap harus di-cache, lakukan partisi berdasarkan identitas atau kelompok (cohort) yang dibatasi dan diverifikasi, cegah penggunaan bersama, tentukan perilaku logout, dan uji isolasi lintas pengguna. Cookie sesi arbitrer dalam public cache key berisiko dan merusak hit rate.

Lanjutan 4: Bagaimana Anda memilih antara satu shield global dan regional shield?

Satu shield memaksimalkan konsolidasi miss tetapi dapat menambah jarak dan memusatkan titik kegagalan. Regional shield mengurangi latensi dan radius dampak tetapi dapat mengambil objek yang sama dari origin beberapa kali. Pilih berdasarkan lokasi origin, kemampuan cache, permintaan regional, latensi yang dapat diterima, dan anggaran origin; kemudian uji failover shield dan dokumentasikan kapan topologi yang dipilih tidak lagi sesuai.

Lanjutan 5: Bagaimana Anda meluncurkan kebijakan cache-key baru?

Kompilasikan sebagai versi konfigurasi baru, lakukan shadow-compute untuk key lama dan baru, lalu bandingkan kardinalitas, hit rate, klasifikasi privasi, dan beban origin tanpa melayani dari key baru. Luncurkan berdasarkan tenant dan PoP, simpan versi rollback, dan hangatkan hanya objek panas yang terbukti. Perubahan key menciptakan peristiwa cold-cache, sehingga harus masuk ke dalam anggaran origin yang sama seperti fill biasa.

Lanjutan 6: Apakah multi-CDN diperlukan untuk ketersediaan 99,99%?

Tidak serta-merta. Satu penyedia dapat memenuhi target jika model kegagalan yang terukur, redundansi PoP, penarikan rute, desain origin, dan operasional mendukungnya. Multi-CDN mengurangi beberapa risiko penyedia tetapi memperkenalkan konsistensi DNS atau steering, konfigurasi duplikat, koordinasi purge, normalisasi log, penanganan sertifikat, dan masalah origin-shield bersama. Terapkan hanya setelah menguji bahwa control plane tambahan benar-benar meningkatkan target ketersediaan yang dinyatakan.