Multi-supplier inventory came together in one model, and the same volume dropped to 20% lower cloud cost.

On a platform serving bus and rail inventory at global scale, we moved a set of dissimilar supplier APIs onto a shared internal model, isolated the sources of failure and built a protection layer that holds continuity under heavy traffic.

%20lower cloud cost 10K+ RPSof proven scale 7/24monitoring and traffic protection
Problem

Every supplier imposed its own model

Inventory arrived from several suppliers, each with its own data model, business rules and failure behaviour. When those differences leaked into the product, two things followed: every new supplier integration was written from scratch, and a fault at one supplier looked to the user as though the entire platform had broken.

Where it started

  • Supplier-specific behaviour leaking into product code
  • Station and city matches corrected by hand
  • Root cause of an incident established by argument rather than evidence
  • Instability during peaks and under hostile traffic
Architecture flow

From supplier to user.

The layers inventory passes through on its way from supplier to user, and what each layer is responsible for.

Inventory flow architecture Supplier A Supplier B Supplier C n more Integration LLM NORMALIZASYON SIMILARITY + VECTOR DB GIS / PLACES MATCHING SUPPLIER CONTRACT Shared internal model SEARCH · DETAIL · SALE RETRY · TIMEOUT CIRCUIT BREAKER GRACEFUL FALLBACK Edge protection WAF · RATE LIMITING CHALLENGE FLOWS ADAPTIVE ROUTING THROTTLING User Observability METRICS · LOGS · DISTRIBUTED TRACING · ALERTING — ISOLATING SUPPLIER / INTERNAL / PAYMENT FAILURES
Each supplier connects to the integration layer through its own contract; once translated into the shared internal model, product flows run independently of any supplier. The edge protection layer filters excessive and malicious traffic, while the observability layer isolates which layer a failure originated in.
Approach

We handled it
in four layers.

We built integration as a permanent layer that suppliers can be added to, not as a one-off job.

01 Integration

Shared internal model

Each supplier’s business logic was analysed and aligned to a single platform contract.

What we did
  • End-to-end analysis of provider APIs and abstraction of their behavioural differences
  • Station / city matching: proximity, name similarity, GIS and Google Places
  • A repeatable integration template that speeds up adding a new supplier
02 AI

Data normalisation

We brought unstructured supplier data up to standard through model-driven flows rather than by hand.

What we did
  • Free-text fields converted to a standard format through OpenAI-based normalisation
  • Automatic model alignment with LLaMA and similarity scoring
  • Matching accuracy improved through similarity search over a vector database
03 Observability

Root-cause isolation

We made degradation across the search, detail and purchase flows visible in real time.

What we did
  • End-to-end traceability through metrics, logs and distributed tracing
  • Degradation caught early through automated alerting thresholds
  • Supplier, internal-system and payment failures separated from one another
  • Conversion tracking by region and supplier, with flow adjustments made alongside the strategy team
04 Resilience

Traffic protection and continuity

We stopped instability in the outside world from spreading into the core systems.

What we did
  • Retry, timeout and circuit breaker patterns applied end to end
  • Continuity during partial failure through graceful fallback and degraded mode
  • Malicious traffic filtered through Cloudflare WAF, rate limiting and challenge flows
  • Adaptive routing and throttling according to region and supplier load
Results

What changed?

We tracked the outcomes not only as technical metrics but alongside their effect on product and operations.

Platform behaviour

A predictable product experience, independent of any supplier.
Model
Multi-supplier inventory unified into one internal model; product code freed of supplier detail.
Continuity
One slow dependency no longer stops the whole flow; the system degrades in a controlled way.
Visibility
The source of an incident (supplier / internal system / payment) can be isolated within minutes.
Cost
Unused services were removed and resources resized; the same workload is served at roughly 20% lower cost.
Team
Faster development through GitHub Copilot adoption, with prompt and usage standards.

Our role

Technical leadership and end-to-end responsibility.
Role
Tech lead · architecture, standards and mentoring
Scope
Architecture, integration, observability, traffic protection, cost
Ways of working
Delivered jointly with the product, strategy and payments teams

Technology

The main components running in production.
AWS.NETOpenAI API LLaMAVector DBOpenTelemetry JaegerCloudflareRedis ElasticsearchRabbitMQ
Related platform solution

This project is the origin of our travel distribution platform solution.

If you have a similar platform need, this is where we would start.

Travel Distribution Platform → All platform solutions →
Disciplines used on this project

Related disciplines

03 · Service Systems Integration & API Engineering Contract-first API design, anti-corruption layer and data normalisation. 06 · Service Site Reliability Engineering Observability, resilience patterns and root-cause isolation. 07 · Service Application & API Security WAF, rate limiting, challenge flows and adaptive throttling.
Let’s work together

Do you run a platform that works with several suppliers too?

Tell us about your current integration setup and we will decide together where to start.

Start a project → See all our work