---
title: "Long-Tail Refresh Scheduling"
description: "Travel inventory'de hot ve long-tail entity'leri demand, volatility, freshness ve cost sinyalleriyle farklı yenileme frekanslarında planlayın."
slug: "long-tail-refresh-scheduling"
translationKey: "architecture-long-tail-refresh-scheduling"
locale: "tr"
type: "guide"
category: "architecture"
tags: ["scheduling","refresh","long-tail","inventory","crawler"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
---

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

```text
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