Architecture Case Study
Architecture Decisions
Key integration decisions, rationale and accepted trade-offs.
Keep supplier integration server-side
Decision
Authentication, SOAP/XML handling and supplier communication stay behind a backend boundary.
Rationale
These concerns require secrets, controlled network access and protocol-specific logic that do not belong in a public browser.
Trade-off
The solution introduces an additional backend service into the synchronous customer journey.
Treat live availability as authoritative
Decision
Use the external API for live availability and price rather than treating synchronised catalogue data as sufficient.
Rationale
The customer result depends on the current search request and current supplier state.
Trade-off
Customer search inherits some latency and availability characteristics of the external dependency.
Expose a website-oriented internal contract
Decision
Transform supplier responses into a stable model designed for the website.
Rationale
Webflow should consume business-relevant result fields without being coupled to SOAP/XML or supplier-specific nesting.
Trade-off
The transformation layer must be maintained when either side of the contract evolves.
Keep booking outside the initial system boundary
Decision
The integration supports search and browse while booking remains with the supplier journey.
Rationale
This limits security, transactional and session complexity and keeps the architecture aligned to the immediate customer need.
Trade-off
The customer journey includes an onward handoff rather than a fully owned booking experience.
Respect the controlled network boundary
Decision
External calls originate from an integration environment that satisfies supplier network-access constraints.
Rationale
Connectivity is part of the external contract and must be treated as an architectural constraint.
Trade-off
Deployment topology is influenced by supplier connectivity requirements.