Design YouTube-Style Search Predictions

Create an evidence-backed design for a resilient search prediction service.

Introduction

30 Second Summary

A search box feels instant when useful suggestions appear after only one or two letters. When millions of people type the same first letter, that effortless moment can become one of the hardest parts of the product to keep fast.

In this project, you will create an evidence-labeled YouTube-style search prediction design in Excalidraw. Your board will evolve a fragile prefix lookup into a resilient architecture built around an offline index.

What You'll Build

You will present a board where tracing a demonstrates the full journey from a 50-million-term scan to a bounded in-memory lookup that still returns suggestions during failures.

By the end of this project, you'll have:

An evidence legend you can point to while separating public YouTube behavior from your design assumptions.
A failure trace that shows a expanding to 50 million possible matches under the exercise workload. The same trace makes the concentrated peak load visible.
A resilient serving path that keeps returning policy-checked global suggestions from a known-good index during optional-signal failures.
Secret Mission: Guard typo tolerance by keeping one-character or two-character prefixes out of fuzzy search. Longer misspellings can use a bounded correction path.

Are there any prerequisites?

You should be familiar with system design interviews plus basic distributed systems concepts. No coding is required because the project runs entirely in your browser.

Before We Start

Using only your browser, this checkpoint commits you to an evidence-backed YouTube-style search prediction service. Your board will label confirmed behavior as PUBLIC while labeling hypothetical architecture as DESIGN, because YouTube's private implementation is unknown.

Set Up the Evidence-First Design Board

A system design board can look convincing while quietly mixing confirmed product behavior with invented infrastructure. That blend makes the architecture hard to defend in an interview.

Your first move is to give every claim a visible evidence category in Excalidraw. The board will also hold the workload assumptions that drive the later failure test.

In this step, get ready to:

Create the titled architecture board.
Build the evidence legend around four reserved design areas.
Produce a local export containing the workload assumptions.

Open and title the board

The browser editor gives you a blank canvas for the full architecture. Starting with the title keeps the board focused on an evidence-backed reconstruction.

Paste https://excalidraw.com/ into your browser address bar.
Press Return to load the editor.

You should see a blank Excalidraw canvas with drawing tools across the top.

Select the Text tool from the top toolbar.
Add YouTube-Style Search Predictions: Evidence-Backed Design across the top of the canvas.

The title now states the scope of the exercise. It also signals that the design will distinguish evidence from architecture choices.

Build the evidence layout

The legend turns your evidence boundary into a visual rule. Every claim added later can inherit one of its four categories.

Place four small swatches beneath the title with the Rectangle tool.
Give each swatch a different fill color with the color control.

You should see four distinct colors beneath the board title.

Label the four swatches PUBLIC, DESIGN, ASSUMPTION, and FAILURE with the Text tool.

Your four-color legend now gives every future note an evidence status.

What do the evidence labels control?

Use PUBLIC for behavior confirmed by public YouTube material.
Use DESIGN for hypothetical architecture choices made in this exercise.
Use ASSUMPTION for fictional workload inputs used to test the design.
Use FAILURE for bottlenecks exposed by a trace.

Draw four large outlined rectangles in a two-by-two grid beneath the legend.

The canvas should now contain four blank areas for the architecture.

Label the upper-left area Requirements.
Label the lower-left area Offline Pipeline.

The left side now has spaces for workload context and offline preparation.

Label the upper-right area Online Serving Path.
Label the lower-right area Operations.

Your board now has separate areas for requirements, offline processing, online serving, and operations.

Add the workload and save the board

Queries per second, or QPS, turns daily activity into serving load. The peak factor gives the later architecture a concrete stress case.

How does the workload math work?

The exercise produces 100,000,000 × 8 = 800,000,000 requests/day.
Dividing by the seconds in one day gives 800,000,000 ÷ 86,400 ≈ 9,259.26 QPS.
Rounding gives 9,260 average QPS.
Applying the peak factor gives 9,260 × 10 = 92,600 peak QPS.

Add one multiline workload text block to the Requirements area with these seven labels:

ASSUMPTION: 100 million sessions/day.
ASSUMPTION: 8 requests/session.
ASSUMPTION: 10x peak factor.
ASSUMPTION: 1 billion unique historical queries.
ASSUMPTION: 5% beginning with "a".
ASSUMPTION: approximately 9,260 average QPS.
ASSUMPTION: approximately 92,600 peak QPS.

Add one note below the workload block with ASSUMPTION CALCULATION: 100,000,000 × 8 ÷ 86,400 ≈ 9,259.26 ≈ 9,260 average QPS. 9,260 × 10 = 92,600 peak QPS.

The requirements area should now show five workload inputs plus two calculated QPS values.

Apply the legend's ASSUMPTION color to the workload text block.
Apply the same color to the calculation note.

Every workload number now carries a visible assumption label. None of the exercise traffic is presented as YouTube data.

Browser storage can be cleared. A local .excalidraw export gives you an editable checkpoint.

Open Menu in the upper-left corner of Excalidraw.
Select Save to....

A macOS save dialog should open for the editable Excalidraw file.

Set the file name to YouTube-Style-Search-Predictions.excalidraw.
Choose Downloads as the destination.

The save dialog should now show the required filename inside your Downloads folder.

Click Save.

Before you verify the export, which filename do you expect to find in Downloads?

Click Finder in the Dock.
Select Downloads in the Finder sidebar.

You should see YouTube-Style-Search-Predictions.excalidraw in Downloads. That file is the local export of your current board.

Can't find the local export?

Return to the Excalidraw tab.
Open Menu.
Select Save to....
Use YouTube-Style-Search-Predictions.excalidraw as the exact filename.
Choose Downloads before saving again.

Help me diagnose why my Excalidraw file did not save to Downloads.

✔️ Awesome, I've got everything!

Your evidence-first board is saved locally with its legend, design areas, and workload assumptions.

ⓧ I'd like to double check the board

Compare your board and local export with this checkpoint.

The board title is YouTube-Style Search Predictions: Evidence-Backed Design.
The legend contains PUBLIC, DESIGN, ASSUMPTION, and FAILURE.
The canvas reserves areas for requirements, the offline pipeline, the online serving path, and operations.
The workload shows 100 million sessions/day, 8 requests/session, a 10x peak factor, 1 billion unique historical queries, and 5% beginning with "a".
The calculated workload shows approximately 9,260 average QPS plus approximately 92,600 peak QPS.
The local export exists at Downloads/YouTube-Style-Search-Predictions.excalidraw.

Strong start. Your evidence-first board now has a defensible foundation.

Next, you'll draw a naive prefix architecture and make its short-prefix weakness visible.

Expose the Naive Prefix Failure

Your evidence-first board now separates public behavior from interview assumptions. That boundary keeps the next experiment honest.

The first serving design uses query-time prefix search against raw history. This step makes that plausible shortcut face the inputs that reveal its limits.

In this step, get ready to:

Draw a naive request path from the search box to a top-10 response.
Trace a selective prefix that makes the design appear acceptable.
Expose the candidate explosion and concentrated load caused by a one-character prefix.

Draw the naive request path

Every request in this design searches historical terms before producing suggestions. The result depends on how many terms share the requested prefix.

Return to the online serving area on your Excalidraw board.

You should see the empty space reserved for the online path.

Select the rectangle icon in the lower toolbar.
Draw six boxes in a horizontal row.

You should now see six empty stages ready to hold the request flow.

Label the boxes from left to right as Search box, Load balancer, Stateless suggestion API, Historical-query database using query-time startsWith(prefix), Sorting, and Top-10 response.

The boxes now show where the request enters. They also show where matching terms are read before the final response.

Select the arrow icon in the lower toolbar.
Connect each neighboring pair from left to right.

You should see one continuous request path through all six stages.

Add the label DESIGN above the entire path using its legend color.

The label makes the evidence boundary visible. This architecture is an interview design choice.

Why Does This Design Look Plausible?

The load balancer spreads requests across stateless API instances. Each instance can therefore scale without holding session state.

The expensive work remains inside the history lookup and sorting stages. A selective prefix can keep that cost hidden.

Is the Request Path Hard to Read?

Keep the six boxes in one row. Leave enough space between them for trace colors and failure notes.

Check that every arrow points toward the top-10 response. Help me improve the readability of this Excalidraw request path.

Trace the selective prefix

A longer prefix usually narrows the candidate set. This friendly case makes the query-time design appear manageable.

Place the input system des beside the search box.
Draw a highlighted trace from that input through the complete request path.

You should see the longer prefix travel through the database and sorting stages before reaching the response.

Add the note few matching rows beside the historical-query database.
Add the note small sort beside the sorting stage.

The trace now presents a request where the database returns a limited candidate set. The final sort also stays limited.

Label the trace Appears acceptable when few rows match.
Follow the highlighted route with your cursor.

You should see a complete top-10 flow with no obvious bottleneck. The selective prefix has made the naive design look convincing.

Break the design with a short prefix

The longer prefix gives the architecture an easy workload. The one-character case now tests whether that confidence survives.

Before you trace the shorter input, do you expect the same request path to stay manageable?

Place the input a beneath the longer prefix.
Trace the new input through the same request path using a different color.

Both traces now use the same architecture. Only the amount of matching history has changed.

Multiply the existing 1,000,000,000 historical-query assumption by the existing 5% prefix assumption.

The calculation lands at 50,000,000 potential matching terms. This is the intended short-prefix candidate explosion.

Add 1,000,000,000 × 5% = 50,000,000 beside the database.
Change the database-scan annotation to the FAILURE legend color.

The database stage now shows the scale of work hidden by the selective-prefix trace.

Add the label FAILURE: database scan beside the matching-term calculation.
Change the sorting annotation to the FAILURE legend color.

The sort still needs to reduce the huge candidate set before it can return only 10 suggestions.

Add the label FAILURE: sort 50,000,000 terms beside the sorting stage.
Draw several repeated a request markers converging on one logical key range.

The convergence makes the hot key behavior visible. Repeated short-prefix requests pressure the same logical range.

Add 92,600 peak QPS beside the converging request markers.
Label the concentration as one logical key range.

Your board now shows two separate failures. The request performs excessive candidate work while concentrated traffic targets the same range.

What Failed in the Naive Design?

The scan cost grows with the number of matching historical terms. The sort inherits that candidate explosion before selecting the final 10.

Adding stateless API instances does not divide a popular prefix across different logical ranges. The short prefix remains a concentrated workload.

Before your final trace, which stage do you expect to become the first visible bottleneck?

Trace a from the search box to the historical-query database.
Pause at the 50,000,000 candidate annotation.
Follow the trace through the failed sort to the top-10 response.

You should see a one-character request inspecting up to 50,000,000 matching terms before selecting 10 results. You should also see about 92,600 peak QPS concentrated on one logical key range.

You have made the hidden scaling problem visible. Your browser scene now proves why the friendly long-prefix trace was misleading.

Does the Failure Still Look Too Subtle?

Place the candidate calculation directly beside the database. Use the existing FAILURE color on both the scan and sorting annotations.

Make the repeated a requests visibly converge before the database. Help me make this short-prefix failure clearer.

Your browser scene now contains the complete naive design and both traces. Your Downloads/YouTube-Style-Search-Predictions.excalidraw file remains the earlier evidence-board checkpoint.

The failure is exposed. Next, you will move candidate generation out of the request path and into an offline-built index.

Build the Offline Prefix Index

Your Excalidraw board now shows how query-time prefix search can force the request path to inspect 50,000,000 terms for a. The cost grows with the popularity of the prefix.

An offline-built prefix index moves aggregation and ordering outside the request path. This turns each online request into a bounded memory lookup.

In this step, get ready to:

Build the offline pipeline that produces a versioned prefix index.
Document the FST decision beside the weighted-trie alternative.
Separate bounded candidate generation from final ranking.

Draw the offline build pipeline

An offline pipeline converts historical demand into a validated artifact before requests arrive. Normalization standardizes query forms before later stages assign weights.

Return to the reserved offline-pipeline area on your board.
Draw a box labeled DESIGN: anonymized query events.
Draw a box labeled DESIGN: normalization to its right.
Connect anonymized query events to normalization with a right-pointing arrow.
Draw a box labeled DESIGN: aggregation to the right of normalization.
Connect normalization to aggregation with a right-pointing arrow.
Draw a box labeled DESIGN: base weighting to the right of aggregation.
Connect aggregation to base weighting with a right-pointing arrow.

The first half of the pipeline now turns repeated historical events into weighted query candidates.

Draw a box labeled DESIGN: offline policy filtering to the right of base weighting.
Connect base weighting to offline policy filtering with a right-pointing arrow.
Draw a box labeled DESIGN: weighted prefix-index build to the right of offline policy filtering.
Connect offline policy filtering to weighted prefix-index build with a right-pointing arrow.
Draw a box labeled DESIGN: validation to the right of the index build.
Connect weighted prefix-index build to validation with a right-pointing arrow.
Draw a box labeled DESIGN: immutable versioned artifact to the right of validation.
Connect validation to immutable versioned artifact with a right-pointing arrow.

How Does This Bound Online Work?

Normalization gives equivalent query forms a consistent representation.
Aggregation converts repeated events into popularity signals.
Base weighting orders candidates before they reach the serving path.
Validation prevents an invalid artifact from becoming the active index.

Choose the global index structure

A compressed weighted trie stores scored candidates along prefix paths. A finite-state transducer compresses an immutable dictionary for fast in-memory prefix lookup.

The global base changes through versioned artifacts. A small mutable overlay carries fresher trending candidates independently.

Add a note beside the versioned artifact titled DESIGN: Prefix index decision.
Add Alternative: compressed weighted trie for ranked prefix lookup and incremental updates. to the note.
Add Chosen: immutable in-memory FST for the global base index. to the note.
Add Freshness: small mutable overlay for trending candidates. to the note.
Add Both structures are defensible interview answers. to the note.
Apply the legend's DESIGN color to the complete decision note.

Why Use an FST With an Overlay?

A compressed weighted trie supports direct retrieval of highly ranked continuations. It also supports targeted score updates.

An in-memory FST fits an immutable global artifact with explicit versions. The mutable overlay keeps fast-changing trends outside that base.

Separate candidate generation from ranking

Candidate generation retrieves a bounded pool from the available indexes. Secondary ranking applies additional signals before selecting the final suggestions.

Draw a box labeled DESIGN: Candidate generation in the online-serving area.
Connect the existing stateless suggestion API to candidate generation.
Draw a source box labeled DESIGN: immutable in-memory FST global base index beside candidate generation.
Add Precomputed top-K lists inside the global base-index box.
Connect candidate generation to the global base index with a two-way line.
Draw another source box labeled DESIGN: optional mutable trending overlay.
Connect candidate generation to the optional overlay with a two-way line.
Add DESIGN: K = 100 candidates inside the candidate-generation box.

The candidate stage now has a fixed output boundary. Popular prefixes cannot expand that boundary beyond K = 100.

Draw a separate box labeled DESIGN: Secondary ranker to the right of candidate generation.
Connect candidate generation to the secondary ranker.
Draw a response box labeled 10 final suggestions to the right of the ranker.
Connect the secondary ranker to the final response.
Add No online raw-history read beside the new serving path.
Add No million-term sort beside the new serving path.

Before you trace a, do you expect the new path to touch either old failure box?

Trace a from the existing search box through the existing load balancer.
Continue the trace through the stateless suggestion API.
Route the trace into candidate generation.
Route the lookup to the global base index's precomputed top-K list.
Return the bounded candidate list to candidate generation.
Continue the trace through the secondary ranker.
Finish the trace at 10 final suggestions.

You'll see a reach a precomputed in-memory top-K list without reading raw query history. The path no longer sorts millions of matching terms.

That is the pivotal shift completed. Your request path now performs bounded retrieval before a separate ranker chooses the final 10 suggestions.

Does the Trace Still Reach Raw History?

Check that the stateless suggestion API points to candidate generation on the new path.
Confirm that candidate generation retrieves its list from the in-memory FST global base index.
Keep the historical-query database attached only to the earlier naive failure trace.
Ask for help with the serving-path boundary. Help me audit my offline-index and candidate-generation diagram.

The browser scene now contains the offline-index additions. Your local YouTube-Style-Search-Predictions.excalidraw export still reflects the earlier board state.

Your online lookup now has bounded work for every prefix. Next, you will harden that path against hot-prefix traffic and serving failures.

Harden the Serving Path

Your Excalidraw board now returns a bounded candidate set from an in-memory FST. However, millions of requests for a can still converge on the same logical route.

A hot-prefix cache absorbs repeated head requests. Sharding spreads deeper prefixes across the serving fleet.

Replication keeps copies available when a node fails. Together, these controls protect the bounded lookup path from skew plus component loss.

In this step, get ready to:

Expand the request path with regional serving components.
Protect short prefixes with replicated head lists.
Add operational checks plus visible failure drills.

Expand the online request path

Client-side debounce reduces duplicate requests while someone is still typing. Each completed request then enters the regional serving layer.

Regional load balancing distributes traffic across the available serving capacity. Stateless suggestion APIs can accept any request because they do not depend on local user state.

Add a DESIGN-labeled request-entry chain containing client-side debounce followed by regional load balancing followed by stateless suggestion APIs.

You should see every request pass through traffic control before it reaches candidate serving.

Candidate serving checks the hot-prefix cache before consulting the index fleet. A miss continues to the shard router.

The router selects from multiple read-only in-memory index replicas. Each replica serves the immutable global index without reading raw query history.

Extend the online path with the three-stage candidate-serving chain described above.

You should see the cache ahead of the router. Multiple replica boxes should now sit behind the router.

Why use read-only replicas?

The immutable index gives each replica the same global candidate data. Requests can move between replicas without changing their lookup behavior.

A replica failure removes capacity while leaving another copy available. The serving path stays independent of raw query history.

Partition deeper prefixes

Deeper prefixes offer enough variety for partitioning by locale plus prefix range. This spreads the long tail across shards.

Add a DESIGN note beside the shard router stating that deeper prefixes are partitioned by locale plus prefix range.

You should see the router distribute deeper-prefix lookups without sending each request to every shard.

Short prefixes remain concentrated because many users request the same small set of values. Precomputed head lists keep those values near the serving nodes that need them.

Add a DESIGN note beside the serving replicas for one- and two-character head lists replicated or pinned near each serving node.

You should see short-prefix traffic bypass the deeper-prefix partition path through nearby precomputed lists.

Why replicate head lists?

Prefix-range sharding spreads deeper prefixes across the fleet. A popular one-character prefix still concentrates requests on one logical range.

Replicated head lists place the same precomputed answer near every serving node. Hot prefixes can use local capacity instead of one overloaded shard.

Add operations checks and run failures

Observability shows whether bounded lookups remain healthy under real traffic skew. The panel needs signals for demand, latency, index freshness, capacity, and safety.

What should the operations panel track?

QPS by prefix length.
cache-hit ratio.
per-shard load.
p95 latency.
p99 latency.
candidate count.
no-result rate.
active index version.
index age.
replica health.
policy-drop count.

Build an operations panel beside the online path using every check above.

You should see one panel covering traffic concentration, serving performance, index state, replica availability, and policy outcomes.

A cache-miss storm tests whether repeated requests overwhelm the index path. An overloaded shard tests how the design exposes uneven demand.

Replica loss tests whether another in-memory copy can continue serving the request.

Add FAILURE drills for cache-miss storms plus overloaded shard plus replica loss.

You should see each drill positioned beside the component whose behavior it tests.

Before you run the failure trace, do you expect a to require every shard when one replica plus one shard are unavailable?

Cover one serving replica plus one shard with FAILURE markers.
Replay the existing a trace through the surviving path.

You should see a return a cached global list from another replica.

The path does not touch raw query history. It does not fan out across every shard.

That is the resilience test passed: your hottest prefix now survives concentrated demand plus a replica-and-shard failure.

Does the trace still fan out?

Confirm that a reaches the hot-prefix cache before the shard router.
Remove any arrow that sends a to raw query history.
Confirm that another read-only replica retains the global head list.
Use Help me inspect my hot-prefix failure trace.

Your serving path now withstands hot-prefix skew plus component loss. Next, you will add secondary ranking, safety checks, graceful degradation, and versioned index rollouts.

Add Safe Ranking and Rollouts

Your serving path now survives hot-prefix skew. It also routes around isolated replica failures.

That is the hardest traffic pressure handled. Your bounded candidate path now has a resilient base.

A fast global index still needs to work when optional signals disappear. You also need to publish new index data without a global cutover.

In this step, get ready to:

Add evidence-labeled secondary ranking inputs.
Protect every result with policy checks plus graceful degradation.
Roll out a new index version with canary checks plus immediate rollback.

Add evidence-labeled ranking inputs

The bounded K = 100 list is a retrieval result. Secondary ranking orders that small set using relevance signals.

Evidence labels keep public product behavior separate from your hypothetical ranker. This boundary makes the board defensible in an interview.

What counts as public evidence?

YouTube publicly names popularity plus similarity as prediction factors. It also confirms trending searches plus relevant prior searches or watched videos as possible sources.

Your use of locale is a design interpretation of area-based behavior. The ranker structure remains your hypothetical design.

In the Excalidraw board from earlier, add a Secondary ranker box after K = 100 candidate generation.
Connect the bounded candidate list to Secondary ranker.

The board now shows where bounded retrieval ends. It also shows where final ordering begins.

Add global weight as a ranking input.
Add prefix match as a ranking input.

The first two inputs capture broad popularity plus similarity to the typed prefix.

Add locale as a ranking input.
Add trending overlay as a ranking input.

The next inputs let the design account for regional relevance plus changing interests.

Add optional user history as a ranking input.
Attach PUBLIC: popularity beside global weight.

The optional history signal can improve personalization. The global signal stays available without it.

Attach PUBLIC: similarity beside prefix match.
Attach PUBLIC: trending searches beside trending overlay.

These badges identify input categories confirmed by public YouTube guidance.

Attach PUBLIC: relevant prior searches or watched videos beside optional user history.
Attach DESIGN: locale mapping beside locale.

The locale label makes your inference visible. It avoids presenting that ranker input as confirmed product behavior.

Add a note beside the ranker labeled DESIGN: ranker shape, weights, timeouts, merge rules.
Connect Secondary ranker to the existing final 10 response.

Before tracing a request, predict whether every ranking decision now has a clear evidence category.

Trace system des from bounded candidate generation through the ranker.

You will see a bounded candidate set enter secondary ranking. The evidence badges distinguish public input categories from design choices.

Build policy checks and fallbacks

Optional signals can improve relevance. The global index must remain useful when those signals fail.

Policy enforcement also needs two time horizons. The offline stage shapes each index version while the online stage handles urgent removals.

Place offline policy filtering directly before weighted prefix-index build.
Mark the offline policy box as DESIGN.

Every immutable index artifact now starts from a filtered candidate set.

Place a fast denylist or rules check after Secondary ranker.
Mark the post-ranking policy box as DESIGN: urgent removals.

Why filter twice?

Offline filtering keeps disallowed material out of each newly built index artifact. This reduces avoidable policy work during serving.

The post-ranking check handles urgent changes between index builds. Every returned suggestion passes through the latest fast enforcement layer.

Add a Fallback order ladder beside the ranker.
Add personalized + trending + global as the first tier.

The first tier represents the richest response path when every signal is available.

Add trending + global as the second tier.
Add global only as the third tier.

The ladder now ends at a useful global result source. Personalization plus trending remain optional enhancements.

Connect the three tiers from richest response to simplest response.
Connect global only to Secondary ranker.

Before tracing the normal path, predict which fallback tier should handle a request with every optional input available.

Trace a request through the fallback ladder to the post-ranking policy check.

You will see the request use personalized + trending + global. Its final suggestions still pass through the urgent-removal check.

Roll out index versions safely

An immutable index becomes safer to publish when the old version stays available. Side-by-side loading creates room for warming plus canary evaluation.

Why keep two versions loaded?

The candidate version can warm in memory before it serves meaningful traffic. A small canary then exposes latency or quality regressions.

The previous version provides an immediate rollback target. The active pointer can return serving traffic without rebuilding an artifact.

Add a Versioned index rollout panel beside the operations panel.
Add v42: loaded known-good index to the rollout panel.

The rollout panel now has a stable baseline for every comparison.

Add v43: build as the first candidate stage.
Add v43: validate as the next candidate stage.

The candidate index now has explicit construction plus validation gates.

Add v43: load alongside v42 after validation.
Add v43: warm after parallel loading.

Both versions are now resident at the same time. The candidate can warm without replacing the known-good index.

Add v43: canary small traffic slice after warming.
Add a comparison card labeled latency, errors, no-result rate, policy drops.

The canary now has operational plus result-quality checks before wider use.

Add an active pointer between the serving path and the loaded index versions.
Add gradual traffic switch to v43 beside the active pointer.

The active version can now change gradually after the canary passes.

Keep v42 visibly loaded beside v43.
Add a rollback path labeled rejected v43 uses active v42.

The rollout panel now supports promotion plus immediate rollback. A rejected candidate never requires a global cutover.

Before you run the three failure traces, which result source do you expect to remain available in every case?

Add a trace lane labeled DISABLED: personalization.
Cover optional user history inside that trace lane.

The first trace now removes only the personalization source.

Trace a through the first failure lane.

You will see trending + global reach the final policy check. The response still contains global suggestions from the active known-good index.

Duplicate the first trace lane.
Label the duplicate DISABLED: trending.

The second trace carries forward the missing personalization signal. It now removes the trending overlay too.

Trace a through the second failure lane.

You will see global only reach the final policy check. The core service still returns suggestions without optional data.

Add a third trace lane labeled REJECTED: v43.
Mark v43 as rejected inside that lane.

The third trace now tests the rollout boundary instead of an optional ranking signal.

Trace a through the active pointer to v42.

You will see the request stay on loaded v42. Its global suggestions still pass through the final policy check.

You have completed the production safety story. Optional signals can fail while a known-good global index continues serving policy-checked predictions.

Does a trace stop before global results?

Check that every fallback tier retains global as a source. Confirm that the fast policy check sits after secondary ranking.

Make sure v42 remains loaded beside v43. Help me debug my ranking fallback and index rollout traces.

Secret mission

Guard Typo Tolerance from Short-Prefix Explosions

Add a budgeted fuzzy candidate branch for misspelled queries. Short prefixes stay on the exact cached path while longer inputs can use guarded typo recovery.

Clean Up Your Resources

Choose whether to keep your design available, pause your work for later, or delete both copies permanently. The board lives only in Excalidraw browser storage and your Downloads folder, so there are no ongoing charges.

Resources you used:

A completed browser-stored board containing the evidence-labeled search prediction architecture.
A local export at Downloads/YouTube-Style-Search-Predictions.excalidraw.

Keep everything running

No action is needed while you are using the board for interview practice. Keeping both copies gives you a browser version for quick edits and a local backup.

Retain the browser-stored board with its guarded typo-tolerance branch.
Keep Downloads/YouTube-Style-Search-Predictions.excalidraw as your interview-practice artifact.

Pause - I'll come back to this later

Pausing preserves the completed design without leaving a process running. A fresh export protects your latest changes if browser storage is cleared.

Export the completed board again to your Downloads folder as YouTube-Style-Search-Predictions.excalidraw.
Confirm Downloads/YouTube-Style-Search-Predictions.excalidraw appears in Finder.
Close the Excalidraw browser tab.
Load Downloads/YouTube-Style-Search-Predictions.excalidraw into Excalidraw when you return.

Your latest architecture is now saved locally for the next practice session.

Delete - I don't want to use this again

Deleting both copies is permanent, so make sure you no longer need the board for interview practice. This removes the browser scene and its local backup.

In the Excalidraw board from earlier, select every element on the canvas.
Delete the selected elements.
Refresh the browser tab.

You should see a blank canvas after the refresh. This confirms the browser-stored scene has been cleared.

Open the Downloads folder from your Mac Dock.
Move YouTube-Style-Search-Predictions.excalidraw to Trash.
Open Trash from your Mac Dock.
Remove YouTube-Style-Search-Predictions.excalidraw permanently.

The completed board should now be absent from both the browser canvas and your Mac.

Nice Work!

You did it! Your Excalidraw board now presents an evidence-labeled, interview-ready architecture for YouTube-style search predictions.

You've learned how to:

Use evidence labels to separate YouTube's public behavior from assumptions, design choices, and failures. Expose a short-prefix candidate explosion by tracing a through up to 50 million potential matches at roughly 92,600 peak QPS.
Replace unbounded online scanning with an offline-built finite-state transducer that returns a bounded K = 100 candidate set from memory. Feed that set through secondary ranking. Enforce policy filtering before returning the final 10 suggestions.
Build a resilient serving path around hot-prefix caching. Use replication to survive serving-node loss. Apply graceful degradation when optional signals fail. Roll out v43 gradually while retaining v42 for immediate rollback.
Secret Mission: Add guarded typo tolerance so a and yo never enter fuzzy search. Allow youtbe to use a bounded fuzzy path before final policy filtering.

Ready to quiz yourself?