Unknown Outcome
A state where a timeout or connection loss makes it unclear whether the upstream action completed. UNKNOWN should not be treated as FAILED without lookup or reconciliation.
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?
Unknown Outcome 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 →Payment + Booking Distributed Transaction
Model payment and supplier booking as a distributed transaction using authorization, capture, compensation, UNKNOWN outcomes and reconciliation.
Explore →Agentic Travel Transaction Safety
Prevent duplicate booking and payment caused by agent loops, retries and tool invocation using idempotency, side-effect guards and UNKNOWN-aware recovery.
Explore →Booking Timeout / Outcome Unknown Troubleshooting
Diagnose ambiguous travel-booking timeouts without duplicate retries using evidence, authoritative lookup and reconciliation.
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 →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 →