Polling
A method of discovering state changes by periodically querying an API instead of waiting for events. Poll interval, rate limits and eventual consistency should be designed together.
Why it matters
Metasearch fan-out architectures need resilience because upstream latency and data volatility are unavoidable. Cache, timeout and retry decisions affect not only backend performance but also whether the displayed offer is trustworthy. These concepts should be designed with SLOs, freshness and failure isolation.
What does it look like in practice?
When one supplier's p95 latency rises, timeout, circuit breaker and fallback cache may work together. A successful stale fallback can still increase price-quality risk.
Implementation questions
- What is the end-to-end latency budget?
- Are cache age and source timestamps retained?
- Which error classes are retried?
- Can one provider failure degrade every supplier?
Common mistakes
- Retrying every error class
- Optimizing cache hit ratio without freshness
- Allowing one provider to block the entire fan-out
Where does it appear in the travel stack?
Polling commonly appears across resilience, transaction layers. Its implementation should make source-of-truth, identity, freshness and transaction-ownership boundaries explicit.
Related terms
Related technical guides
Booking Timeout and UNKNOWN Outcome Recovery
Recover ambiguous travel-booking timeouts with UNKNOWN state, authoritative lookup, reconciliation and safe retry gates.
Explore →Booking Timeout & Duplicate Prevention Playbook
Handle unknown booking state after create timeouts using idempotency, lookup, payment evidence and reconciliation instead of blind retries.
Explore →Booking Timeout / Outcome Unknown Troubleshooting
Diagnose ambiguous travel-booking timeouts without duplicate retries using evidence, authoritative lookup and reconciliation.
Explore →Cancellation Succeeded but Local State Stale
Diagnose cases where provider cancellation succeeded but local booking state stayed stale across webhook, persistence, ordering and reconciliation layers.
Explore →Canonical Offer, Order and Booking State Model
Design canonical Offer, Order and Booking lifecycle boundaries with an explicit booking state machine for travel integrations.
Explore →NDC Offer/Order Lifecycle: Search to Servicing
Model NDC Offer/Order lifecycle across search, offer, revalidation, order creation, payment, ticketing, servicing and reconciliation states.
Explore →