Bird
Raised Fist0

Design a Search Ranking System - Feature Store, Model Serving, A/B Testing

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Ranking Logic Service

Receives search query from User Client

Starts processing by attempting to fetch features from Redis cache

Protocol:HTTP Request
BeforeUser Client has sent search query; Ranking Logic Service idle
AfterRanking Logic Service received query and initiated feature fetch
Feature Store (Redis Cache)

Checks for features in cache

Cache miss triggers query to Cassandra for features

Protocol:Redis GET
BeforeFeature Store Redis cache does not have features for query
AfterCache miss detected; request forwarded to Cassandra DB
Feature Store (Cassandra DB)

Fetches features from durable store

Returns feature data to Redis cache and Ranking Logic Service

Protocol:CQL Query
BeforeFeature Store Cassandra DB has features stored; no request active
AfterFeature data retrieved from Cassandra DB and sent back to Redis and Ranking Logic Service
A/B Testing Controller

Determines model variant for this request

Sends variant info to Ranking Logic Service for model selection

Protocol:gRPC
BeforeRanking Logic Service has features but no variant info
AfterRanking Logic Service knows which model variant to use
Model Serving

Scores features using selected ML model

Returns ranking scores to Ranking Logic Service

Protocol:gRPC
BeforeModel Serving idle; Ranking Logic Service has features and variant
AfterRanking Logic Service received model scores
Ranking Logic Service

Combines scores and applies final ranking logic

Sends ranked results back to User Client

Protocol:HTTP Response
BeforeRanking Logic Service has model scores and variant info
AfterUser Client receives ranked search results
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  User Client  │
└───────┬───────┘
        │ HTTP Request (Search Query)
        ▼
┌───────────────────────┐
│ Ranking Logic Service  │
└───────┬───────────────┘
        │ Redis GET (Feature Cache)
        ▼
┌───────────────────────────────┐
│ Feature Store (Redis Cache)    │
└───────┬───────────────────────┘
        │ Cache Miss → Cassandra Q
        ▼
┌───────────────────────────────┐
│ Feature Store (Cassandra DB)  │
└───────┬───────────────────────┘
        │ Feature Data Response
        ▼
┌───────────────────────────────┐
│ A/B Testing Controller         │
└───────┬───────────────────────┘
        │ Variant Selection Info
        ▼
┌───────────────────────────────┐
│ Model Serving                  │
│ (TensorFlow Serving + Triton) │
└───────┬───────────────────────┘
        │ Model Scores Response
        ▼
┌───────────────────────┐
│ Ranking Logic Service  │
│ (Final Ranking Output) │
└───────┬───────────────┘
        │ HTTP Response (Ranked Results)
        ▼
┌───────────────┐
│  User Client  │
└───────────────┘
Design Rationale

The Search Ranking System processes a user query by first attempting to retrieve features from a Redis cache within the Feature Store. On a cache miss, it queries Cassandra for durable feature data, which is then cached for future requests. The A/B Testing Controller determines the model variant to apply, enabling controlled experiments. The Ranking Logic Service sends features and variant info to Model Serving, which scores the candidates using TensorFlow Serving and NVIDIA Triton. Finally, the Ranking Logic Service combines scores and returns ranked results to the user. This architecture balances low latency with durability and experiment flexibility.

Primary Focus

✓

Practice

(1/5)
1. A messaging system must guarantee ordered processing of events per user session while supporting high throughput. Which Kafka feature ensures this ordering?
easy
A. Partitioning messages by user session key
B. Setting a short retention policy to reduce storage
C. Using multiple consumer groups to parallelize consumption
D. Using Kafka Streams for message transformation

Solution

  1. Step 1: Understand parallelism vs ordering

    Using multiple consumer groups increases parallelism but does not guarantee ordering per session.

  2. Step 2: Identify ordering guarantee

    Partitioning messages by user session key ensures ordering within partitions.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Multiple consumer groups increase throughput but ordering per session requires partitioning [check]
Hint: Multiple consumer groups increase throughput [OK]
Common Mistakes:
2. In the SLO error budget tracking system, at step 4 the Error Budget Calculator receives aggregated error counts and total request counts. What state does it maintain immediately after processing these inputs?
easy
A. It resets the error budget to full capacity regardless of recent errors
B. It discards error counts if the total request count is below a threshold
C. It queues the error counts for asynchronous processing by the alerting system
D. It updates the current error budget remaining by subtracting recent error rate from total budget

Solution

  1. Step 1: Understand the role of the Error Budget Calculator at step 4

    It updates the remaining error budget by subtracting the recent error rate from the total allowed errors, reflecting current SLO compliance.

  2. Step 2: Exclude other states that contradict error budget tracking logic

    Resetting the budget ignores recent errors; queuing is done later by alerting; discarding counts would lose accuracy.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Error Budget Calculator updates remaining budget after aggregation [check]
Hint: Error budget updates subtract recent errors, not reset or discard [OK]
Common Mistakes:
3. For the fraud detection system's rule engine, which architecture best supports rapid rule updates without downtime while maintaining low latency scoring?
medium
A. Embed rules directly in the scoring service code and redeploy on changes
B. Use an external rule engine service with hot-reloadable rule definitions
C. Store rules in a database and query them synchronously during scoring
D. Compile rules into scoring service binaries and load at startup only

Solution

  1. Step 1: Evaluate embedding rules in code (A) and binaries (D)

    Both require redeployment or restart on rule changes, causing downtime or latency spikes.

  2. Step 2: Assess querying rules synchronously (C)

    Querying rules synchronously adds latency and risk of inconsistent rule versions during scoring.

  3. Step 3: Consider external rule engine with hot-reload (B)

    This allows dynamic rule updates without downtime and low latency via caching and efficient evaluation.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    External hot-reload rule engine -> dynamic updates, low latency [check]
Hint: Hot-reload rule engine enables live updates without downtime [check]
Common Mistakes:
4. If Redis becomes unavailable in a centralized rate limiting system, what is the immediate failure mode for incoming requests?
medium
A. API servers allow all requests without rate limiting, risking overload
B. Requests are queued locally until Redis recovers, causing increased latency
C. API servers reject all requests immediately to avoid exceeding limits
D. API servers switch to a backup Redis instance automatically without delay

Solution

  1. Step 1: Understand Redis unavailability impact

    Without Redis, the centralized counter is unreachable, so rate limiting cannot be enforced.

  2. Step 2: Check fallback behavior

    Most implementations allow requests to proceed without rate limiting to avoid blocking, risking overload.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Redis down -> no rate limiting -> requests allowed unchecked [check]
Hint: No Redis means no rate limiting, requests pass unchecked [check]
Common Mistakes:
5. At 10x scale, which component in the Ticket Server pattern is most likely to become the bottleneck first, and why?
hard
A. Ticket Server, because it handles all block allocations and cannot be sharded easily
B. Clients, because local ID block exhaustion causes frequent server requests
C. Network, because increased traffic saturates bandwidth between clients and server
D. Database storing allocated blocks, because it cannot handle concurrent writes at scale

Solution

  1. Step 1: Identify centralization bottleneck

    The Ticket Server centrally allocates ID blocks and maintains allocation state, limiting horizontal scaling.

  2. Step 2: Compare other components

    Clients scale horizontally; network scales with infrastructure; database load is less critical if Ticket Server caches state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Ticket Server centralization -> first bottleneck at 10x scale [check]
Hint: Central Ticket Server state limits horizontal scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard