Stale Price & Delayed Feed Troubleshooting

A stale price exists when upstream offer state has changed but an older state continues to be served. Feed delay, long TTLs, failed invalidation or replay backlog can all produce the same symptom.

Observable symptom

A supplier has published a new price but metasearch still shows the old amount; closed inventory remains visible; or certain property/date combinations update hours late.

Most likely causes

The source feed may be delayed, ingestion can fail or backlog, event ordering can break, cache invalidation may fail, TTL may be too long, worker retries can accumulate, clocks can disagree, or downstream indexes can refresh late.

Fast triage order

Find four timestamps for the same offer:

1. provider state changed,
2. event/feed received,
3. normalized/persisted,
4. served/rendered.

The largest gap usually identifies the first layer to investigate.

Evidence to collect

Persist source_changed_at, source_sent_at, ingested_at, normalized_at, cache_written_at, cache_expires_at and served_at.

Without that timeline, “feed or cache?” becomes guesswork.

Diagnostic decision tree

If the source never changed, the offer is not stale.

If the source changed but no event arrived, inspect provider/feed transport.

If the event arrived but DB state is old, inspect ingestion/normalization.

If DB is current but API is old, inspect cache/indexes.

If API is current but UI is old, inspect CDN/client cache or rendering.

False positives

Indicative prices, “from” prices and intentionally cached discovery datasets are not live offers. Define expected freshness for each product contract first.

Fix and validation

Apply replay, cache purge, retry, ordering or TTL changes at the responsible layer. A manual cache clear alone is not root-cause resolution.

Run a controlled source change and measure end-to-end propagation latency.

Metrics proving resolution

Track p50/p95 freshness lag, stale-offer rate, queue age, ingestion failures, cache age and unavailable-after-click.

Prevention

Store observed/source-updated timestamps for every price and define separate freshness SLOs for discovery versus booking-intent flows.