Long-Tail Refresh Scheduling

Tüm hotel, route veya content entity'lerini aynı frekansta refresh etmek pahalıdır ve çoğu zaman yanlış önceliklendirmedir. Long-tail scheduling'in amacı refresh bütçesini demand ve change probability'ye göre dağıtmaktır.

Production senaryosu

100 bin property var. İlk 5 bin property trafiğin %80'ini üretirken kalanların çoğu haftada birkaç kez aranıyor. Hepsini 15 dakikada bir crawl etmek supplier quota ve infrastructure cost'u boşa harcar.

Priority score

Örnek sinyaller:

• recent search volume,
• booking/click value,
• observed price volatility,
• time-to-travel,
• last successful refresh age,
• provider health,
• change frequency,
• business priority.

Scheduling modeli

Entity Signals
 -> Priority Score
 -> Freshness Class
 -> Next Refresh At
 -> Queue
 -> Worker
 -> Observation
 -> Score Update

Hot / warm / cold

Hot entity kısa interval, warm orta interval, cold uzun interval kullanabilir.

Sınıflar sabit değil, davranışa göre değişmelidir.

Starvation riski

Pure popularity scheduling long-tail entity'leri hiç refresh etmeyebilir. Maximum-age guard koyun: düşük trafikli entity bile belirli sürede en az bir kez yenilenmeli.

Jitter

Binlerce kaydın aynı dakika refresh olması burst yaratır. next_refresh_at üzerine jitter uygulayın.

Failure modes

• hot set'in queue'yu ele geçirmesi,
• provider quota starvation,
• cold entity'nin aylarca yenilenmemesi,
• failed refresh'in agresif retry ile queue'yu doldurması,
• score feedback loop'un dengesizleşmesi.

Cost-aware scheduling

Provider request cost veya rate limit'i score'a dahil edin. Aynı freshness value daha ucuz provider'dan elde edilebiliyorsa plan değişebilir.

Observability

• refresh age percentile,
• queue age,
• hot/warm/cold distribution,
• refreshes per useful click/booking,
• stale hit rate,
• provider quota burn,
• starvation count.

Alternatifler

Küçük dataset'te cron ile full refresh yeterlidir. Büyük ve skewed demand dağılımında priority scheduler anlamlı hale gelir.

Production checklist

• priority score
• maximum-age guard
• jitter
• failure backoff
• provider quota awareness
• dynamic class transitions
• queue age alert
• cost/freshness KPI