The Slow/Fast Call Orchestration: Parallelizing for Perception

You hit “play” on a video. Seconds pass, but nothing happens — just that spinning wheel. It’s a small delay, but it feels huge.

Now imagine a different experience: the video starts playing almost instantly. The first few seconds are slightly lower resolution, but by the time you register it, the stream has already sharpened to full HD. On slower networks — the kind that can sustain HD once the stream stabilizes but are too sluggish to start it quickly — this change is transformative. A tiny shift in how data is delivered can completely reshape how fast the experience feels. A moment that once felt like waiting suddenly becomes a moment of progress.

In distributed systems, a similar idea underpins a pattern where the most essential information is returned through a lightweight, fast path, while heavier or secondary data loads are processed in parallel. The user sees meaningful content immediately, and by the time they’re ready to scroll or interact further, the rest has quietly arrived. This approach doesn’t cheat physics or shrink payload sizes; instead, it restructures the order of work so that perceived value shows up as early as possible.

This design approach is known as slow/fast call orchestration. It’s a practical, high-impact technique for improving perceived performance without compromising completeness or correctness. Instead of forcing the system to wait for the slowest part of a request, it unlocks the ability to serve what truly matters first - and do the rest in the background.

Why Do It?

Let’s take search as a concrete example.

In most search architectures, a query fans out to several sources or verticals — people, posts, jobs, companies — in the case of LinkedIn. Each vertical computes its own ranked list, and the aggregator merges these into a final results page before anything is rendered.

But in many common user actions — such as clicking on a typeahead suggestion — the primary intended result is already known. The user’s choice makes the top hit deterministic. Yet the system still waits for slower, less relevant verticals to finish processing before showing anything. That delay is pure opportunity cost: the experience could have felt instant.

Slow/Fast orchestration shifts that dynamic by splitting work into two coordinated paths. It treats the initial user intent as a strong signal and optimizes for immediate reinforcement of that intent, rather than waiting for every subsystem to complete. In scenarios where intent is clear, showing the right thing quickly is often more valuable than showing everything at once.

The Core Idea: FAST and DEFAULT Paths

The architecture introduces a dual-path execution model for eligible requests running in parallel:

FAST path – A lightweight request that returns the top cluster or primary hit immediately, without waiting for slower verticals. Its purpose is not completeness, but instant usefulness. It leverages already-determined signals to short-circuit heavy work and surface the most relevant content as soon as possible.

DEFAULT path – A full execution of the standard search workflow: fetching, ranking, aggregating, and ordering results across all verticals. This path ensures correctness, completeness, and high-quality blended output.

The client renders the FAST response instantly, and then quietly swaps in (or augments it) with the DEFAULT response once it arrives. For most users, this feels like the page loaded faster. The reality is subtler: the system simply delivered the right thing earlier.

This decoupling lets a user see the most relevant content hundreds of milliseconds sooner while still preserving the integrity of the full result set. And importantly, it requires no product compromises or alternate “partial render” versions of search.

Architectural Considerations

Avoiding Duplication

Since both paths may include the same top hit, the system must either dedupe the DEFAULT results or replace the FAST-hit with the canonical hit from the DEFAULT response. Each choice affects tracking complexity and consistency, and the decision often comes down to how the frontend manages incremental updates and whether hit identities must remain stable.

Tracking Consistency

Telemetry must be aware of the two-path model. Otherwise, metrics like action attribution and hit impressions risk double-counting or misattribution when the UI transitions from FAST to DEFAULT. Getting this wrong can distort ranking evaluation, experimentation, and long-term quality signals.

Resilience and Fallbacks

If the FAST path fails, the DEFAULT path still provides full functionality. This makes the optimization safe - a performance win without weakening reliability or creating new failure modes.

Rethinking Metrics

Traditional page-load metrics (like time-to-first-byte or page-complete) usually don’t capture incremental rendering. New metrics should distinguish between time-to-first-meaningful-render and time-to-full-results. Without this distinction, real improvements in perceived latency remain invisible in dashboards.

Scaling and Performance Trade-Offs

This dual-orchestration approach increases QPS, but in predictable ways and only for targeted segments. With caching and request deduplication, the extra load is manageable - and vastly outweighed by user-perceived gains. The FAST path is intentionally cheap, so even the increased traffic carries minimal marginal cost.

What we saw in practice

• ~300ms reduction (P95) in time-to-first-byte — a 17% improvement in perceived load time (from ~1800ms).
• The FAST path effectively capped perceived latency for the primary hit and related UI components.
• The architecture created headroom to experiment with higher-latency relevance models or richer result annotations without harming usability.
• Users experienced near-instant visual feedback, as the top hit and its surrounding insights appeared immediately.

This is the essence of perceived performance: the system feels faster because the right things show up sooner. Even though the total work stays the same, shifting what arrives first makes the experience radically better.

Conclusion

Slow/fast call orchestration shows how rethinking the execution flow — not hardware or infrastructure — can deliver meaningful latency improvements. By separating deterministic work from blended, compute-heavy workflows, the system becomes faster, more resilient, and more scalable all at once.

More importantly, it aligns system behavior with user perception: progress appears immediately, the interface remains responsive, and quality is preserved. This principle also laid the foundation for subsequent enhancements, such as the streaming of result clusters, which further improved the perceived performance of the DEFAULT path.