When your page speed
belongs to somebody else

A comparison site's core transaction is fanning one customer's details out to a couple of dozen insurers and presenting what comes back. RedRate did that synchronously and waited for everyone, which meant the slowest partner set the page time and any partner failure looked like a RedRate failure.

The situation

The quote journey called every partner API in parallel and waited for the full set before rendering. In steady state that was tolerable. Under a marketing campaign, with partner APIs also under load from every other comparison site running campaigns, it was not.

Two failure modes dominated. A slow partner held the whole page, so the customer saw a spinner while eighteen perfectly good quotes sat in memory. And a partner returning errors produced an error page rather than a shorter list, which is a strictly worse outcome for everyone including that partner.

• Quote page time set by the slowest partner in the set
• Partner failures surfacing as journey failures
• Campaign traffic arriving in the first ninety seconds of a send
• No per-partner view of latency, error rate or cost contribution

What we built

Progressive results

The journey now renders as soon as it has a usable set and streams the remainder in, with partners still outstanding shown as pending rather than omitted. Customers see prices in a fraction of the previous time and the late partners still get their impression.

A budget per partner, not per request

Each partner integration has its own timeout, concurrency limit and circuit breaker, tuned to that partner's observed behaviour rather than a single global value. A partner that starts failing is shed quickly and retried on a schedule, and its problems no longer propagate.

Caching what is genuinely cacheable

Rating factors and product metadata change on a daily cadence, not a per-request one. Separating those from the quote call removed a meaningful share of partner traffic, which improved RedRate's latency and reduced load on partners simultaneously.

Elastic capacity against the campaign calendar

The quote services moved to EKS with Karpenter, pre-scaled on the marketing schedule rather than reactively. Campaign traffic arrives faster than any autoscaler responds, so the capacity is in place before the email lands.

Completion rate is measured as journeys reaching a quote comparison, not policy sales.

The hard part

Parallelism made things worse before it made them better. Increasing concurrency to partners pushed several of them into their own rate limits, which returned throttling responses that our retry logic dutifully amplified. From RedRate's monitoring it looked like partner instability; from the partner's side it looked like RedRate attacking them.

The fix was per-partner concurrency budgets with adaptive back-off, plus — the unglamorous half — actually talking to the partners about their published limits, several of which turned out to be wrong in both directions.

Half of an integration resilience project is engineering. The other half is a conversation with the people on the other end of the API.

One partner also returned HTTP 200 with an error document in the body. Every health check considered it healthy while it served nothing but failures. Response validation now happens on content rather than status code, which is the sort of thing you only build after it has cost you a weekend.

Where it landed

Time to a usable set of quotes fell by well over half, and completed journeys rose meaningfully — the two are related, and the uplift was largest on mobile connections where the previous wait was worst.

The platform absorbed a campaign peak of roughly fourteen times baseline without degradation, and cost per completed quote fell despite the higher volume, because caching removed partner calls that were never adding anything.