Current-State Architecture

Baseline assumption

Existing digital journeys could rely heavily on catalogue-oriented data flows.

flowchart LR
    S[Travel source]
    C[Local catalogue / index]
    W[Website experience]
    U[Customer]

    S -->|scheduled or controlled sync| C
    C --> W
    W --> U

This model works when the customer-visible product state can be represented accurately enough by synchronised data.

Why live holiday search is different

For the holiday supplier, the result depends on the customer's current search inputs and the supplier's current availability.

Relevant inputs include:

• departure airport;
• destination;
• departure date;
• duration;
• occupancy;
• child ages where applicable;
• room requirements.

A local catalogue can support discovery, but it cannot by itself become authoritative for live availability and price.

Architectural implication

The website therefore needs an integration path that can participate in the request:

customer criteria
     ↓
website
     ↓
backend integration
     ↓
live supplier search
     ↓
normalised result
     ↓
website

That changes the architecture from synchronise then browse to request, integrate and present.

The target architecture had to make that live dependency explicit rather than hide it behind catalogue assumptions.