Architecture Case Study
Architecture Decisions
Key decisions, rationale and accepted trade-offs in the search architecture.
Separate search from presentation
Decision
Search execution is provided by a dedicated service rather than embedded in Webflow/browser logic.
Rationale
Search, faceting, ranking and pagination are platform capabilities with different scaling and operational characteristics from page presentation.
Trade-off
The organisation owns another runtime service and integration contract.
Keep Webflow as the presentation layer
Decision
Webflow remains responsible for the customer-facing page and components.
Rationale
The architecture should improve search without replacing the established presentation platform.
Trade-off
Stable DOM/component integration points still require coordination between frontend and integration changes.
Use a search-oriented information model
Decision
Index a flattened projection containing the fields needed for discovery instead of mirroring the source record unchanged.
Rationale
The search model should optimise for customer queries and facets.
Trade-off
Transformation rules become part of the maintained architecture.
Separate public and privileged access
Decision
Public search uses restricted search-only authority; index administration remains behind controlled backend tooling.
Rationale
The browser should receive only the permissions required for customer search.
Trade-off
Administrative operations require a separate integration path.
Treat the index as reproducible
Decision
The search service is not the authoritative product store.
Rationale
Search state should be recoverable from source data and mapping rules.
Trade-off
Refresh, rebuild and freshness monitoring become explicit operational responsibilities.