Konteks dan arahan
Sebuah gateway cache menambahkan Warning: 110 - "Response is stale" dan Warning: 111 - "Revalidation failed". Peramban (browser) dan layanan hilir (downstream) tidak secara konsisten menampilkan field-field ini, dan standar-standar yang lebih baru tidak lagi merekomendasikannya. Jelaskan semantik historis, batas validasi cache, field pengganti, dan migrasi tanpa kehilangan data (lossless).
Pertanyaan ini cocok untuk wawancara backend, gateway, CDN, dan platform. Kuncinya adalah memisahkan metadata protokol, error pengguna, dan observabilitas internal daripada mengganti satu header yang usang dengan header bentuk bebas (free-form) lainnya.
Apa yang sedang diuji oleh pewawancara
Jawaban yang kuat menjelaskan bahwa Warning dulunya dapat mendeskripsikan masalah pesan dan bahwa peringatan 1xx terkait cache dapat dihapus setelah validasi berhasil. Jawaban tersebut juga mencatat bahwa field ini telah usang karena tidak dihasilkan atau ditampilkan secara luas, sementara sebagian informasinya dapat disimpulkan dari field seperti Age. Kandidat harus menggunakan Cache-Control, Date, Age, validator, kode status, dan metrik terstruktur alih-alih kontrak klien berbentuk bebas.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
- Apakah Warning dihasilkan oleh origin, shared cache, atau edge gateway, dan apakah ada beberapa lapisan proxy?
- Apakah 110 dan 111 hanya untuk diagnostik, atau apakah klien mengubah perilaku bisnis karenanya?
- Apakah respons menyertakan
Date,Age,Cache-Control,ETag, danLast-Modified? - Klien warisan (legacy) mana yang harus didukung, dan bisakah sistem melakukan penulisan ganda (dual-write) untuk sementara waktu?
- Siapa yang membutuhkan "fresh", "stale", dan "revalidation failed": pengguna, logika bisnis, atau operator?
Kerangka jawaban 30 detik
"Saya akan memperlakukan Warning sebagai diagnostik cache historis, bukan kontrak error pengguna yang stabil. 110 mendeskripsikan respons basi (stale) dan 111 mendeskripsikan revalidasi yang gagal, tetapi field ini sudah usang dan tidak cocok untuk teks bebas. Saya akan menginventarisasi konsumen dan lapisan proxy, mengekspresikan fakta dengan Cache-Control, Date, Age, validator, dan metrik terstruktur, melakukan dual-write hanya untuk jendela kompatibilitas yang berbatas waktu, lalu menghapus Warning setelah mengamati perilaku klien. Metrik cache hit rate, stale serving, kegagalan revalidasi, dan error budget akan memverifikasi migrasi ini."
Jawaban mendalam langkah demi langkah
Langkah 1: Memulihkan peran historis Warning
Warning adalah header permintaan dan respons yang berisi kode tiga digit, agen pembuat, dan teks. Kode 110 dan 111 yang terkait dengan cache mendeskripsikan respons basi dan revalidasi yang gagal; keduanya bukan kode status HTTP dan tidak berarti 4xx atau 5xx. Beberapa proxy dapat menambahkan field ini secara beruntun, membuat sumber dan tingkat kepercayaan teks bebas menjadi tidak stabil.
Langkah 2: Menjelaskan mengapa migrasi diperlukan
MDN menandai Warning sebagai usang (deprecated) karena tidak dihasilkan atau dimunculkan secara luas dan standar yang relevan tidak lagi merekomendasikan mekanisme peringatan umum ini. Mengandalkannya akan mengikat diagnostik cache ke teks yang tidak stabil dan membuat duplikasi, pengurutan ulang, atau pemfilteran proxy sulit dianalisis. Pertama-tama, buktikan bahwa tidak ada klien yang memperlakukannya sebagai sinyal bisnis.
Langkah 3: Mengekspresikan fakta dengan field cache standar
Date mengidentifikasi waktu pembuatan respons, sedangkan Age memperkirakan waktu tinggal di shared cache. Cache-Control menentukan persyaratan kesegaran (freshness) dan revalidasi, dan ETag atau Last-Modified mendukung permintaan bersyarat (conditional requests). Bersama-sama, mereka mendeskripsikan status cache; string kustom X-Warning bukanlah pengganti. Origin juga harus menyetel Vary dengan benar agar representasi untuk permintaan yang berbeda tidak tercampur.
Langkah 4: Memindahkan diagnostik ke dalam observabilitas
Gateway harus mencatat peristiwa terstruktur seperti cache_status=stale, revalidation=failed, upstream=timeout, lapisan cache, dan trace ID. Log harus menghindari nilai kueri URL yang sensitif; metrik harus diagregasi berdasarkan rute, keluarga kunci cache (cache-key family), dan kelas error upstream. Respons hanya boleh membawa status yang relevan bagi pengguna, sedangkan detail operasional tetap berada dalam sistem yang terkontrol.
Langkah 5: Merancang jendela dual-write untuk kompatibilitas
Hentikan penggunaan Warning pada traffic bayangan (shadow traffic) atau rute kecil terlebih dahulu, periksa dependensi pada SDK, skrip, dan aturan proxy. Jika ada klien warisan, pertahankan Warning sebentar sambil memublikasikan field pengganti atau panduan peningkatan (upgrade guide). Penggantinya memerlukan enum yang stabil dan kontrak berversi, bukan teks arbitrer yang disalin. Tetapkan tanggal akhir (sunset date) yang jelas untuk dual-write.
Langkah 6: Menangani cache berlapis dan kegagalan validasi
Revalidasi yang gagal tidak selalu berarti origin sedang down; itu bisa berupa timeout, permintaan bersyarat yang ditolak, atau 5xx dari upstream. Putuskan apakah akan menyajikan konten basi (stale content), mengembalikan error, atau menerapkan kebijakan stale-if-error, dan catat alasannya. Menghapus Warning tidak boleh menyembunyikan penyajian stale atau membuat percobaan ulang tanpa henti (infinite retries).
Langkah 7: Memisahkan 103 Early Hints dari peringatan cache
103 Early Hints mendahului respons akhir dan memberikan petunjuk tentang kemungkinan sumber daya, umumnya melalui Link untuk preconnect atau preload. Header ini tidak melaporkan kesegaran cache atau kegagalan revalidasi dan tidak menggantikan Age atau Cache-Control. Nyatakan waktu, konsumen, dan semantik kegagalan dari setiap field daripada memperlakukan setiap petunjuk sebagai Warning.
Langkah 8: Menghapus secara bertahap dan memverifikasi
Bandingkan pembacaan Warning, rasio cache hit, rasio penyajian stale, keberhasilan permintaan bersyarat, error origin, latensi P95, dan error klien sebelum dan sesudah migrasi. Nonaktifkan pembuatan pada satu lapisan cache, perluas ke seluruh rantai, lalu hapus kode, dokumentasi, dan peringatan (alerts) setelah klien warisan bersih. Sakelar rollback hanya boleh memulihkan output kompatibilitas, jangan pernah memulihkan ketergantungan bisnis pada Warning.
Trade-off dan batasan
Mempertahankan Warning memiliki biaya kompatibilitas jangka pendek yang rendah tetapi memperpanjang kontrak yang tidak stabil dan pemecahan masalah yang ambigu. Penghapusan langsung mengurangi kebisingan protokol tetapi dapat merusak skrip warisan. Jalur teraman adalah mengamati dependensi nyata, lalu memindahkan kebutuhan tersebut ke field cache standar dan observabilitas terstruktur.
Jangan mengartikan Age sebagai waktu pembuatan origin atau Cache-Control: no-cache sebagai "jangan simpan di cache"; header tersebut memerlukan revalidasi sebelum digunakan kembali. Kebijakan cache, validator, dan respons error harus dirancang dengan jendela kesegaran yang dapat diterima oleh bisnis.
Rencana peluncuran dan bukti
Pada minggu pertama, ekspor jalur pembacaan Warning dari edge, shared cache, dan klien, untuk menetapkan baseline berdasarkan rute dan lapisan cache. Selanjutnya, lakukan dual-write metrik terstruktur pada rute tanpa dependensi kritis dan bandingkan Age, permintaan bersyarat, dan tingkat error. Terakhir, nonaktifkan Warning lapis demi lapis sambil mempertahankan sakelar output kompatibilitas satu klik.
Penerimaan (acceptance) memerlukan: tidak ada klien produksi yang membaca Warning; rasio cache-hit dan keberhasilan revalidasi tidak mengalami regresi; peristiwa stale-if-error dapat dijelaskan; log dan metrik berkorelasi berdasarkan trace ID; serta dokumen, SDK, dan alert telah diperbarui.
Jebakan umum dan tindak lanjut
Memperlakukan 110 sebagai 4xx atau 5xx
110 adalah kode Warning historis, bukan status respons. Error bisnis termasuk dalam kontrak status dan respons; diagnostik cache termasuk dalam metrik.
Membuat ulang masalah dengan X-Warning
Teks bebas, penambahan oleh proxy, dan kompatibilitas versi tetap tidak pasti. Jika kompatibilitas diperlukan, gunakan enum yang stabil, versi, dan konsumen yang eksplisit.
Menghapus header tanpa observabilitas
Menghapus field tidak memperbaiki penyajian stale atau revalidasi yang gagal. Tetapkan metrik status cache, penelusuran (tracing), dan peringatan sebelum menghapus header eksternal.
Memperlakukan 103 Early Hints sebagai peringatan cache
Waktu dan tujuan 103 adalah petunjuk sumber daya; ia tidak dapat mengekspresikan kesegaran atau kegagalan revalidasi. Pisahkan field dan jalur pemrosesan.
Bagaimana Anda membuktikan bahwa itu dapat dihapus?
Amati pembacaan klien, konfigurasi proxy, tingkat error, dan metrik cache; jalankan jendela dual-write berbatas waktu dan perluas setelah canary satu lapisan. Jangan menghapus secara global tanpa bukti dependensi.