Push vs Pull vs Hybrid for Travel Distribution

Push, pull and hybrid models solve distribution with different freshness and ownership trade-offs. Choose based on state volatility + latency budget + retry/reconciliation cost, not traffic volume alone.

Comparison matrix

When push fits

Push is effective for source-driven ARI, inventory, restriction and durable property/content changes.

Source state changes
  -> event/delta
  -> queue
  -> partner adapter
  -> delivery ledger
  -> acknowledgement

The key risk is confusing delivery success with business-state convergence.

When pull fits

When price/availability is highly volatile and the user request already defines entity/date context, live pull can be more accurate.

User search
  -> provider request
  -> live response
  -> normalize
  -> render

The main risk is allowing a slow provider to consume the entire search latency budget.

Why hybrid is common

A natural travel-metasearch pattern is:

Property/content master -> feed/push/cache
Broad price coverage    -> cached/pushed state
User-selected context   -> live search/reprice
Final handoff           -> validation/reconciliation

Using one sync model for both stable and volatile data usually creates unnecessary cost or stale state.

Idempotency and ordering

Push requires event identity and source version.

Pull looks like an idempotent read, but cache fill, analytics and downstream side effects can still duplicate.

In hybrid systems, unclear ownership can allow old pushed state to overwrite a newer live observation.

Failure modes

Push

• lost events,
• out-of-order deltas,
• retry storms,
• silent drift.

Pull

• provider timeouts,
• quota exhaustion,
• thundering herd,
• partial results.

Hybrid

• cache/source conflict,
• stale pushed state overriding live truth,
• inconsistent TTL/revalidation.

Observability

Track update-delivery latency, stale-data age, polling volume, webhook/event failures, retry count, duplicate-event rate and reconciliation backlog together.

Decision rule

If data changes slowly and read volume is high, push/cache can be efficient.

If data is highly volatile and request context has high cardinality, live pull/reprice is usually safer.

Most production travel systems become hybrid, but each field must have explicit source and freshness ownership.

Checklist

• Is source of truth explicit per field?
• Is freshness budget defined?
• Are event ordering/version rules defined?
• Is cache invalidation/revalidation explicit?
• Is rate-limit pressure measured?
• Is partial-result behavior defined?
• Is periodic reconciliation implemented?