Cache dapat langsung mengembalikan stored response yang sudah expired dan memulai validation secara paralel ketika stale-while-revalidate mengizinkan reuse tersebut. Request yang menemukan stale entry karena itu tidak harus ikut menanggung origin validation latency, tetapi dapat menerima representation data yang lebih lama daripada normal freshness lifetime.

Ini adalah pergeseran yang disengaja dalam cache contract. Freshness tetap berakhir pada boundary yang dikonfigurasi. Extension menambahkan interval terpisah tempat stale reuse diizinkan sementara validation berlangsung, sehingga response age dan request latency menjadi sebagian terpisah.

Freshness expiry dan stale reuse adalah boundary yang berbeda

Pertimbangkan response directive berikut:

Cache-Control: max-age=60, stale-while-revalidate=30

Stored response bersifat fresh selama 60 detik pertama usianya, sesuai HTTP cache age calculation. Dalam interval tersebut, cache biasanya dapat menggunakannya kembali tanpa menghubungi origin.

Setelah freshness berakhir, stale-while-revalidate=30 mengizinkan reuse selama tambahan 30 detik. Jika cache menyajikan stale response melalui extension ini, cache sebaiknya mencoba validation tanpa memblokir response tersebut menunggu hasil validation.

Dua interval itu menyatakan properti berbeda:

age 0s                         60s                         90s
|------------------------------|---------------------------|
          fresh reuse              stale reuse permitted
                                   during revalidation

Interval kedua tidak memperpanjang freshness. Interval itu mengizinkan stale service secara terbatas. Perbedaan ini penting untuk observability dan correctness karena response dapat secara sah disajikan ketika sudah stale.

Validation tetap merupakan conditional origin interaction

HTTP validation memungkinkan cache menanyakan apakah stored representation masih dapat digunakan tanpa mentransfer full representation lagi. Stored validator seperti entity tag dapat dikirim dalam conditional request. Jika origin melaporkan selected representation belum berubah, cache dapat memperbarui stored metadata dan tetap menggunakan body yang ada.

Dengan stale-while-revalidate, interaksi tersebut dipindahkan keluar dari latency path request yang memicunya. Client dapat menerima stale object sementara cache menjalankan conditional exchange secara terpisah.

Directive ini tidak mendefinisikan validator baru dan tidak membuat validation menjadi tidak diperlukan. Directive ini mengubah kapan stale response boleh digunakan relatif terhadap validation.

Jika origin mengembalikan replacement representation, request berikutnya dapat menggunakan entry yang telah di-refresh. Jika validation mengonfirmasi stored representation, metadata-nya dapat diperbarui sesuai aturan cache normal. Jika validation tidak selesai sebelum stale allowance berakhir, extension ini sendiri tidak lagi mengizinkan stale reuse berlanjut.

Traffic yang jarang dapat mengekspos akhir stale window

Background refresh sering dijelaskan seolah cache terus memperbarui object saat mendekati expiry. Protocol mechanism tidak mewajibkan scheduler seperti itu.

Request yang datang setelah object menjadi stale dapat memicu perilaku asynchronous validation. Jika tidak ada request yang tiba selama permitted stale interval, request-driven validation tidak perlu terjadi.

Misalkan response memiliki freshness lifetime 60 detik dan stale-while-revalidate allowance 30 detik. Jika request datang pada usia 10, 40, dan 95 detik, dua request pertama dapat menggunakan fresh response. Request pada detik ke-95 berada di luar stale allowance 30 detik milik extension. Request tersebut tidak dapat mengandalkan stale-while-revalidate untuk segera memperoleh response lama.

Bentuk traffic karena itu memengaruhi apakah perilaku latency-hiding benar-benar dijalankan. Object yang sering diminta lebih mungkin menerima request di dalam stale interval daripada object dengan idle period panjang.

Concurrent stale request tidak harus berarti concurrent origin work

Protocol mengizinkan stale service selama revalidation, tetapi tidak mewajibkan satu origin validation request untuk setiap client request. Implementasi cache dapat mengoordinasikan refresh work sehingga beberapa request menerima stale object yang sama sementara satu validation sedang berjalan.

Koordinasi tersebut adalah properti implementasi, bukan jaminan yang diberikan directive. Tanpa coalescing seperti itu, beberapa request yang tiba setelah expiry dapat masing-masing memicu origin traffic walaupun client menerima stale response.

Boundary ini memisahkan dua concern. stale-while-revalidate mengizinkan stale reuse dan mendeskripsikan intended non-blocking validation behavior. Request collapsing, single-flight refresh, lock granularity, dan distributed coordination antar-cache node adalah mekanisme implementasi yang terpisah.

Multi-node cache menambahkan layer lain. Setiap node dapat memiliki stored response dengan age dan validation state sendiri. Kecuali produk cache mengoordinasikan refresh lintas node, in-flight validation pada satu node tidak berarti node lain menekan origin request miliknya sendiri.

Directive ini menukar bounded staleness dengan request-path latency

Tanpa izin menggunakan kembali stale response, cache yang membutuhkan validation dapat menempatkan requesting client di belakang origin round trip. Dengan stale-while-revalidate, eligible stale response dapat memenuhi request tersebut terlebih dahulu.

Biayanya eksplisit: client dapat melihat data yang lebih lama daripada freshness lifetime. Maximum extra age yang berasal dari directive ini dibatasi oleh delta value-nya, dengan asumsi tidak ada rule lain yang secara independen mengizinkan stale reuse.

Kondisi tersebut penting. HTTP memiliki cache control dan operational policy lain yang dapat memengaruhi stale service. Nilai stale-while-revalidate bukan universal maximum age untuk seluruh kemungkinan perilaku cache; itu adalah batas yang melekat pada permission khusus ini.

Karena itu, directive ini tidak cocok sebagai pengganti application consistency protocol. Resource yang konsumennya mengharuskan validation sebelum setiap stale reuse memerlukan cache contract yang lebih ketat. Pengurangan latency tidak dapat menghapus perbedaan semantic antara fresh state dan stale state.

Revalidation failure tidak sama dengan stale-if-error

Refresh attempt dapat gagal karena origin tidak tersedia atau mengembalikan error. stale-while-revalidate dan stale-if-error menangani kondisi berbeda.

Yang pertama mengizinkan stale service untuk interval terbatas sementara validation berlangsung. Yang kedua dapat mengizinkan stale service ketika terjadi error, dalam staleness bound miliknya sendiri.

Response dapat membawa kedua directive:

Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=300

Nilai tersebut menyatakan permission yang berbeda. Selama 30 detik pertama setelah freshness expiry, stale-while-revalidate dapat mengizinkan immediate stale service sementara refresh berjalan. Error handling dapat memiliki stale allowance berbeda melalui stale-if-error.

Menggabungkan keduanya tidak mengubah nilai tersebut menjadi satu continuous freshness period. Freshness tetap berakhir pada boundary max-age, dan setiap stale mechanism berlaku sesuai kondisinya sendiri.

Revalidation directive dapat menutup stale path

HTTP cache directive dapat memberlakukan reuse requirement yang lebih ketat. Secara khusus, must-revalidate mewajibkan successful validation sebelum stale response digunakan kembali.

Response policy karena itu harus dievaluasi sebagai sekumpulan directive, bukan dengan membaca stale-while-revalidate secara terpisah. Menambahkan stale extension ke response yang directive lainnya melarang stale reuse tersebut tidak menciptakan unconditional escape dari requirement yang lebih ketat.

Ini juga merupakan configuration boundary antara application intent dan intermediary behavior. Origin menyatakan permission dan restriction melalui response metadata; conforming cache menerapkan aturan tersebut saat memutuskan apakah stored response dapat memenuhi request berikutnya.

Cache age tetap menjadi observable state

Menyajikan stale content dalam mode ini tidak mereset usia stored response hanya karena validation sudah dimulai. Sampai validation atau replacement mengubah cache state, object tetap stale.

Field Age dapat memperlihatkan berapa lama response telah berada di cache sesuai HTTP age calculation. Karena itu, field ini berguna untuk membedakan low-latency cache hit dari response yang baru diperoleh dari origin.

Operational metric membutuhkan pembedaan yang sama. Cache-hit ratio yang tinggi dapat hidup berdampingan dengan volume stale response yang berarti. Memperlakukan setiap hit sebagai setara dapat menyembunyikan sisi consistency dari latency trade-off.

Cache telemetry yang berguna dapat memisahkan fresh hit, stale hit, validation attempt, validation result, origin error, dan request yang blocking setelah stale allowance berakhir. Kategori tersebut berhubungan dengan protocol state yang berbeda walaupun client pada akhirnya menerima successful response.

Stale window adalah consistency budget

stale-while-revalidate paling presisi jika diperlakukan sebagai bounded permission, bukan generic performance switch. Directive ini memberi cache ruang untuk menyajikan expired representation sementara refresh work berjalan di luar critical path request pemicu.

Configured delta karena itu merupakan bagian dari consistency policy resource. Nilai yang lebih besar memperpanjang interval ketika request latency dapat menghindari validation, sekaligus memperpanjang interval ketika expired representation boleh dikembalikan melalui mekanisme ini.

Protocol menjaga properti tersebut tetap eksplisit: freshness memiliki satu boundary, stale reuse memiliki boundary lain, dan validation tetap menjadi operasi yang menghubungkan kembali cached state dengan current representation milik origin.