volvocars.com — Commerce Platform
The car configurator had a 3-second latency problem. The fix wasn't where the problem appeared — it was a level up, in the data model and the API layer.
The volvocars.com commerce platform handles car configuration, offer selection, and vehicle search across dozens of global markets. Every option change in the configurator — trim, colour, powertrain — was taking 3 seconds, because each one triggered a round-trip to origin. The instinct was to cache harder. That turned out to be the wrong level to solve it at.
The problem was a level up
Vehicle configurations are combinatorial: a single market can have tens of thousands of valid configurations, each with pricing, availability, and eligibility rules that vary by dealer and market. Caching at the response level was a dead end. The real constraint was the API: a REST layer serialising full configuration objects on every call. Moving to a federated GraphQL schema let the UI request only what a given interaction needed, composed from subgraphs that could be cached independently.
Half the interactions didn’t need the network at all
Colour, interior trim, and accessory changes can be validated client-side against a pre-fetched configuration graph. We built a local validation layer that handled those without touching the network — making roughly half of all customer interactions in the configurator synchronous from the user’s point of view, and bringing end-to-end latency from 3 seconds to under 500ms.
Scale
The platform serves millions of sessions across 50+ markets, with engineering teams across multiple countries contributing to the codebase — coordinated through shared architecture standards and a federated ownership model rather than central gatekeeping.