Request Coalescing Menggabungkan Cache Miss yang Terjadi Bersamaan

Cache miss dapat menjadi mahal ketika banyak request meminta key yang sama pada waktu hampir bersamaan. Tanpa koordinasi, setiap caller dapat memulai query database, remote call, atau komputasi yang identik. Cache akhirnya terisi, tetapi backend menerima burst tepat ketika nilai cache sedang tidak tersedia.

Request coalescing mengubah batas concurrency tersebut. Caller pertama memulai load dan menerbitkan in-flight entry untuk key itu. Caller berikutnya bergabung ke entry tersebut alih-alih memulai pekerjaan ekuivalen. Setelah load selesai, hasilnya dibagikan kepada caller yang menunggu lalu in-flight entry dihapus.

Mekanisme ini mengurangi duplicate work; biaya dan reliabilitas load dasarnya tidak berubah dengan sendirinya.

Coalescing key menentukan pekerjaan yang boleh dibagi

Hanya request dengan semantik ekuivalen yang boleh memakai in-flight entry yang sama. Cache key yang hanya memakai URL dapat berbahaya jika authorization, locale, tenant, header, atau query parameter mengubah hasil.

Karena itu, coalescing key perlu memuat pembedaan yang membuat nilai hasil load aman untuk dipakai bersama. Key yang terlalu luas dapat mengembalikan hasil keliru. Key yang terlalu sempit tetap benar tetapi kehilangan kesempatan untuk menggabungkan pekerjaan duplikat.

Batas ini terpisah dari layout storage. Dua cache entry dapat memakai sumber backend yang sama tanpa berarti keduanya ekuivalen secara semantik.

Satu leader menjalankan load

Request pertama untuk key yang tidak ada menjadi leader. In-flight state dibuat sebelum backend work dimulai agar caller lain tidak melihat miss lalu menjalankan load kedua di celah tersebut.

Follower menempel pada state yang sama dan menunggu completion. Implementasi dapat memakai promise, future, condition variable, channel, atau primitive khusus runtime. Properti utamanya adalah publikasi atomik untuk satu active load per coalescing key.

Setelah completion, cleanup harus memungkinkan miss berikutnya memilih leader baru. In-flight entry yang sudah selesai atau gagal tidak boleh tertinggal tanpa batas karena state sementara dapat berubah menjadi hasil stale atau error permanen.

Kegagalan memerlukan policy fan-out yang eksplisit

Berbagi pekerjaan juga berarti berbagi hasilnya. Jika leader menerima timeout atau backend error, semua follower yang menunggu attempt tersebut dapat menerima kegagalan yang sama.

Retry independen secara langsung oleh semua follower akan membuat ulang burst yang hendak ditekan oleh coalescing. Retry policy harus tetap terbatas dan terkoordinasi, baik attempt berikutnya dijalankan satu caller maupun ditunda sampai request berikutnya.

Sebagian sistem menyimpan negative result tertentu dalam cache untuk waktu singkat. Pendekatan itu dapat mengurangi kerja berulang untuk kondisi stabil seperti objek yang dipastikan tidak ada, sedangkan transient failure biasanya memerlukan perlakuan berbeda.

Cancellation satu caller tidak boleh membatalkan semuanya

Follower dapat berhenti membutuhkan hasil ketika caller lain masih menunggu. Cancellation milik follower biasanya cukup melepaskan follower tersebut tanpa menghentikan backend work milik leader.

Kasus leader lebih rumit. Jika caller awal disconnect, shared operation masih dapat berguna bagi follower. Implementasi dapat memisahkan lifetime in-flight load dari satu caller tertentu dan membatalkan backend hanya ketika tidak ada waiter yang masih berkepentingan atau shared deadline sudah habis.

Policy tersebut tetap membutuhkan batas waktu. Detached load tanpa deadline dapat terus memakai resource setelah seluruh caller yang berguna sudah pergi.

Hot key tetap memerlukan admission control

Coalescing dapat mengubah seribu miss bersamaan menjadi satu backend operation, tetapi tekanan pada sisi waiter tetap ada. Hot key masih dapat mengumpulkan banyak suspended caller, retained buffer, atau pekerjaan response fan-out.

Batas waiter per key, global concurrency limit, deadline, dan load shedding tetap berguna. Coalescing mengendalikan eksekusi backend yang duplikat; mekanisme ini bukan pengganti pembatasan demand.

Pembedaan yang sama berlaku ketika backend sama sekali tidak dapat melayani key tersebut. Ribuan waiter yang berbagi satu operasi yang akan gagal tetap memakai resource lokal sampai operasi selesai.

Scope menentukan apakah instance dapat berbagi pekerjaan

Coalescer di dalam process hanya menggabungkan request yang mencapai process yang sama. Sepuluh service instance masih dapat menjalankan sepuluh backend load secara bersamaan untuk satu key.

Coalescing lintas instance dapat memakai distributed lock atau coordination service, tetapi menambah network dependency, lease handling, ownership recovery, dan persoalan stale holder. Pada banyak sistem, coalescing per instance sudah cukup mengurangi amplifikasi tanpa menempatkan distributed coordination pada read path.

Scope yang tepat mengikuti biaya yang hendak dilindungi. Database yang mampu menerima satu load per application instance mungkin tidak memerlukan koordinasi global.

Metric perlu menunjukkan collapse dan contention

Telemetry yang berguna mencakup jumlah leader load, follower join, durasi tunggu, follower per key, backend latency, error, cancellation, serta rasio logical request terhadap actual load.

Collapse ratio yang tinggi dapat menunjukkan bahwa coalescing sedang melindungi hot key. Nilai tersebut juga dapat menandakan cache policy yang membuat entry populer kedaluwarsa dalam burst tersinkronisasi. Metric perlu dibaca bersama cache hit rate, eviction behavior, dan saturasi backend.

Request coalescing paling efektif ketika pekerjaan ekuivalen yang terjadi bersamaan cukup sering dan mahal. Key yang presisi, pemilihan leader secara atomik, bounded waiting, cancellation yang cermat, dan failure handling eksplisit membuat banyak caller dapat berbagi satu in-flight operation tanpa mengubah shared state itu menjadi sumber masalah correctness atau availability baru.