Platform module
Supplier control center
Onboarding, credentials, mapping runs and honest health data.
How does TravelCore handle a slow or failing supplier?
Searches fan out to every supplier in parallel under a per-supplier time budget. A connector that exceeds its budget is actually cancelled, named in the response, and the result set is marked partial rather than the search failing. Connectors that burn an error budget are shed automatically for a cooldown, then readmitted with a clean window.
A distribution platform is only as good as its worst supplier on its worst day. The control center makes supplier behaviour visible instead of anecdotal: response time distributions rather than averages, booking success rate, error taxonomy, and the share of searches where a supplier returned nothing in time.
Onboarding a supplier is a defined path: credentials stored in a secrets manager and never in the database, sandbox verification, a content and rate mapping run, a shadow period where the supplier's results are collected but not sold, and only then production traffic.
Each connector carries an error budget. When a supplier burns through it, the platform sheds it from the search fan-out automatically rather than letting it drag every search down, and retries it after a cooldown so a recovered connector returns on its own.
The aggregation layer is real code and it runs on this page — the same modules the test suite imports, covered by 22 tests. It is also the only place on the site where all three engines work together: suppliers fan out in parallel with per-supplier time budgets, the matcher resolves their offers into unified properties, and the pricing engine turns each net rate into a selling price. Make a supplier hang and watch the result set shrink while the page keeps working.
Capabilities
- Supplier onboarding workflow with a mandatory shadow period
- Credentials in a secrets manager, never in application storage
- Sandbox and production credential separation
- Content, rate and room mapping runs with diff review
- Response-time percentiles by nearest rank, so the number is a latency a request actually experienced
- Booking success rate and error taxonomy per supplier
- Error budgets with automatic shedding from the search fan-out
- Per-supplier revenue and margin contribution
Run it yourself
Make a supplier slow and watch the result set, not the page, degrade
This is the only place on the site where all three engines run together: four suppliers fan out in parallel, the matcher resolves their offers into unified properties, and the pricing engine turns each net rate into a selling price. Break one and search again.
Supplier behaviour
Break a supplier and search again
Four connectors, each with its own latency. The one that hangs will miss its budget, and after enough failures it burns its error budget and stops being called at all.
sup_alpha
120ms
sup_beta
120ms
sup_gamma
8000ms
sup_delta
120ms
A supplier that misses this is aborted and reported. It never delays the response.
Related
The rest of the core
Booking engine
One flow from search to voucher, for every product type.
Pricing and markup engine
Net rate to final price, by rule, versioned and auditable.
Hotel mapping and normalisation
The same property from many suppliers, resolved to one object.