Current-State Architecture

Baseline

The existing experience combined catalogue delivery, filtering logic and rendering inside the customer-facing page.

flowchart LR
    S[Travel product sources]
    D[Legacy data delivery]
    W[Webflow page]
    J[Browser-side search/filter scripts]
    U[Customer results]

    S --> D
    D --> W
    W --> J
    J --> U

Architectural concerns

Presentation and search were coupled

The frontend needed to understand both the product representation and how to filter it.

More data moved to the browser

As the catalogue grew, the client increasingly became responsible for work better suited to a search engine.

Integration scripts became a contract

Selectors, IDs, data mappings and filtering behaviour accumulated inside custom scripts. Changes to the Webflow page therefore risked affecting data behaviour.

Source model leaked into the experience

Without an intermediate search model, frontend behaviour was more directly influenced by upstream data structures.

Why change was required

The current state made it difficult to scale search capability independently from page design.

The target needed to introduce a clear boundary:

source systems
    ↓
search-oriented projection
    ↓
search capability
    ↓
Webflow presentation

That boundary became the organising principle for the target architecture.