Package Holiday Distribution Architecture

A package holiday is not merely the arithmetic sum of a hotel and a flight. Turkish package-tour definitions cover combinations of transport, accommodation and other tourism services sold together. Architecturally, a package offer can be derived from component offers but needs its own identity, price, cancellation rules and booking state.

Problem and why it matters

Hotel inventory can be valid, flight inventory valid and transfer available while the package is still not bookable. Component availability and package availability are not equivalent. Tour-operator contracts, allotments, departure rules, insurance, margin and package-level cancellation terms create additional state.

Canonical data model

PackageOffer
 ├─ packageId
 ├─ departureDate / returnDate
 ├─ travelers
 ├─ destination
 ├─ components[]
 │   ├─ HotelComponent
 │   ├─ FlightComponent
 │   ├─ TransferComponent
 │   └─ OtherServiceComponent
 ├─ totalPrice
 ├─ currency
 ├─ priceComponents[]
 ├─ cancellationPolicy
 ├─ source / tourOperator
 ├─ observedAt
 └─ bookingReference / sourceOfferRef

Component supplier IDs should be preserved. Package identity must not be collapsed into hotel ID or flight itinerary ID.

Bundle identity

The same hotel and flight can represent different packages when room type, meal plan, baggage, transfer or cancellation conditions differ. Fingerprinting only provider and total price creates false merges.

Pricing

Package price does not have to equal the sum of hotel, flight and transfer retail prices. Contracted net rates, markup, discounts, child pricing, occupancy and campaign rules can alter the package result.

Keep component gross/net values, package total, mandatory taxes/fees, discount and margin/commission separately.

Availability and freshness

Each component can change on a different clock. Hotel allotment may close, a flight fare family may disappear or a transfer cutoff may pass. Keep package observedAt together with component freshness rather than one shared timestamp.

Booking lifecycle

SEARCH
 → PACKAGE_SELECTED
 → REPRICE
 → COMPONENT_HOLD / VALIDATION
 → PAYMENT_AUTHORIZED
 → COMPONENT_CONFIRMATIONS
 → PACKAGE_CONFIRMED

If one component confirms while another fails, explicit states such as PARTIAL_CONFIRMATION or UNKNOWN are safer than blind retry.

Cancellation and amendment

Package cancellation is not simply the sum of component policies. A tour operator may apply package-level terms while components have different refundable states.

Failure modes

Typical risks include traveler-count mismatch, occupancy/passenger-type mismatch, currency normalization errors, stale package price, missed transfer cutoff, partial booking, duplicate component reservations and lost supplier references.

Observability

Track package-search-to-reprice success, component validation failures, stale-price delta, partial-confirmation rate, duplicate-booking rate, cancellation reconciliation drift, margin and abandonment.

Trade-offs

Dynamic packaging improves combination flexibility but increases search-space, pricing and orchestration complexity. Pre-built packages provide tighter control but less flexibility and real-time supply coverage.

Production checklist

• Separate package and component identity.
• Preserve source/provider references.
• Separate package total from component prices.
• Reprice before booking.
• Model partial confirmation explicitly.
• Keep component-level idempotency.
• Reconcile cancellation at package and component level.
• Observe freshness per component.