Sync vs Async Travel Booking Architecture

Choosing sync or async booking is not a framework preference. It defines the boundary between provider response semantics and the booking contract exposed to the traveler.

Short answer

Synchronous orchestration can be enough when the provider returns a definitive CONFIRMED/FAILED result within a predictable budget and supports authoritative recovery after timeouts. Use an asynchronous state machine when confirmation is delayed, delivered by webhook, or has highly variable latency.

Synchronous booking

Synchronous booking flow

Mermaid source (.mmd)

Benefits include simple UX and fewer moving parts. Risks include long-running requests, ambiguous timeouts, duplicate retries and direct exposure to provider latency.

Asynchronous booking

Asynchronous booking flow

Mermaid source (.mmd)

The client can receive a non-terminal state such as PENDING, PROCESSING or UNKNOWN.

Decision matrix

Hybrid model

Many production systems are hybrid: wait for a short synchronous budget, transition to PENDING/UNKNOWN when it expires, continue reconciliation in the background, and accept webhook evidence whenever it arrives.

Failure modes

• blind retry after HTTP timeout,
• marking async work FAILED too early,
• endless pending when webhook is lost,
• treating client disconnect as booking cancellation,
• applying both synchronous response and webhook twice.

Observability

Track synchronous completion rate, async fallback rate, confirmation latency percentiles, pending/unknown age, reconciliation time and duplicate-event rate.

Production checklist

Use explicit terminal/non-terminal states, separate transport timeout from business timeout, provider-specific budgets, idempotency, webhook deduplication, reconciliation fallback, polling backoff and manual-operations thresholds.