Bird
Raised Fist0

Faceted Search and Filtering at Scale

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Faceted Search and Filtering at Scale
45 min · senior
senior

You are building a faceted search and filtering system for a large e-commerce platform with 50 million daily active users. Users expect to filter products by multiple attributes (e.g., brand, price range, color, ratings) with sub-200ms P99 latency. The system must encrypt data at rest and in transit due to regulatory requirements. The product catalog updates frequently (thousands of updates per minute), and the search index must reflect changes with minimal delay. The system should support complex boolean filters and sorting, and scale horizontally to handle peak traffic.

Constraints
  • Support 50M DAU with peak QPS of 150K search requests
  • P99 latency under 200ms for search queries with multiple facets
  • Data encrypted at rest and in transit (TLS + disk encryption)
  • Index updates must reflect product catalog changes within 1 minute
  • Support complex multi-dimensional filters and sorting
  • Horizontal scalability with zero downtime deployments
📋
Guided Steps
1/5
Step 1
Data Storage and Indexing Strategy
How would you store and index product data to support fast faceted search with frequent updates?
💡 Hint
Consider a search engine optimized for inverted indexes and real-time indexing like Elasticsearch or OpenSearch.
Key Decision
Use Elasticsearch with index sharding by product category and document routing by product ID to enable fast inverted index lookups and near real-time updates.
Interviewer Expectation
Mid-level: Names Elasticsearch for faceted search. Senior: Explains shard key choice, routing by product ID for update locality, and how inverted indexes enable fast multi-facet filtering.
⚠️Common Wrong Answer
Using a relational database with complex SQL queries for faceted search - leads to slow query times and poor scalability at 50M DAU.
Step 2
Handling Real-Time Updates and Index Consistency
How will you ensure product catalog updates are reflected in the search index within 1 minute while maintaining query performance?
💡 Hint
Think about near real-time indexing pipelines and asynchronous update propagation using message queues.
Key Decision
Use Kafka as a change data capture (CDC) pipeline to stream product updates to Elasticsearch indexers, enabling near real-time indexing with eventual consistency under 1 minute.
Interviewer Expectation
Mid-level: Mentions Kafka for streaming updates. Senior: Details CDC integration, partitioning by product ID for update ordering, and how Elasticsearch refresh intervals balance latency and query performance.
⚠️Common Wrong Answer
Direct synchronous updates to Elasticsearch on every product change - causes high write latency and query slowdowns.
Step 3
Query API Design for Faceted Search
Design the API endpoints for clients to submit search queries with filters, retrieve facet metadata, and refresh cached results.
💡 Hint
Consider RESTful endpoints with JSON payloads supporting multi-dimensional filters and pagination.
Key Decision
Expose a POST /search endpoint accepting JSON with filters, sorting, pagination; a GET /facets endpoint returning available facet values and counts; and a GET /refresh-token endpoint for clients to obtain tokens to invalidate caches.
Interviewer Expectation
Mid-level: Defines basic search and facets endpoints. Senior: Explains filter DSL design, pagination tokens, and cache invalidation via refresh tokens to reduce stale data.
⚠️Common Wrong Answer
Using GET with query parameters for complex filters - leads to URL length limits and poor expressiveness.
Step 4
Security and Encryption
How will you ensure data encryption at rest and in transit for the faceted search system?
💡 Hint
Consider TLS for network encryption and disk-level encryption or encrypted storage volumes.
Key Decision
Use TLS 1.3 for all client-server and inter-service communication, and enable Elasticsearch encrypted snapshots with AWS KMS-managed keys for data at rest encryption.
Interviewer Expectation
Mid-level: Mentions TLS and disk encryption. Senior: Details TLS version, certificate rotation, encryption key management with KMS, and audit logging for compliance.
⚠️Common Wrong Answer
Relying only on network firewalls without TLS - exposes data to interception and violates compliance.
Step 5
Scaling and High Availability
How will you design the system to scale horizontally and maintain availability during deployments?
💡 Hint
Think about stateless API servers, Elasticsearch cluster scaling, and blue-green or canary deployments.
Key Decision
Deploy stateless API servers behind an autoscaling group with load balancers, use Elasticsearch clusters with shard replication and cross-cluster replication, and implement blue-green deployments with health checks to avoid downtime.
Interviewer Expectation
Mid-level: Describes autoscaling and replication. Senior: Explains shard rebalancing impact, cross-cluster replication for disaster recovery, and deployment strategies minimizing query impact.
⚠️Common Wrong Answer
Single Elasticsearch cluster without replication - leads to data loss and downtime during failures.
🔌
API Design Challenge
Sketch 3 core API endpoints for the faceted search system: how clients submit search queries with filters, how they retrieve filter metadata (facets), and how they receive updates or refresh tokens for cache invalidation.
Hints
  • How does the client specify multiple filters and sorting in the search request?
  • What metadata is needed to render available facets and counts?
  • How can clients efficiently refresh or invalidate cached search results?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of Elasticsearch with appropriate sharding and routing for faceted search
  • Near real-time indexing pipeline using Kafka CDC for product updates
  • API design supporting complex filters, facets metadata, and cache invalidation
  • Encryption in transit (TLS) and at rest (encrypted snapshots with KMS)
  • Horizontal scalability with stateless APIs and replicated Elasticsearch clusters
Good to Have - 30%
  • Blue-green or canary deployment strategy for zero downtime
  • Pagination and cursor tokens for efficient deep paging
  • Cross-cluster replication for disaster recovery
Bonus - 10%
  • Audit logging and key rotation strategy for encryption keys
  • Advanced filter DSL supporting nested boolean logic
Anti-patterns to Avoid
✅
Model Answer
▼ Reveal

This design uses Elasticsearch with sharding by product category and routing by product ID to enable fast faceted search with near real-time updates. Kafka streams product catalog changes as CDC events to Elasticsearch indexers, ensuring index freshness within 1 minute. The API exposes POST /search for complex filter queries, GET /facets for facet metadata, and GET /refresh-token for cache invalidation. TLS 1.3 secures all network communication, and AWS KMS-managed encrypted snapshots protect data at rest. Stateless API servers behind autoscaling load balancers and replicated Elasticsearch clusters ensure horizontal scalability and high availability. Blue-green deployments with health checks enable zero downtime upgrades.

Key Decisions
  • Use Elasticsearch for faceted search with shard key as product category and document routing by product ID to optimize query and update locality
  • Implement Kafka as CDC pipeline to stream product catalog changes asynchronously to Elasticsearch indexers, achieving near real-time indexing within 1 minute
  • Design RESTful API with POST /search accepting JSON filter DSL supporting boolean operators and pagination tokens, GET /facets returning facet metadata with counts, and GET /refresh-token for cache invalidation tokens
  • Enforce TLS 1.3 for all client-server and inter-service communication, and enable encrypted snapshots in Elasticsearch using AWS KMS-managed keys for data at rest encryption
  • Deploy stateless API servers behind autoscaling groups with load balancers, and Elasticsearch clusters with shard replication and cross-cluster replication for disaster recovery
  • Adopt blue-green deployment strategy with health checks to ensure zero downtime during system upgrades
  • Elasticsearch with sharding by product category and routing by product ID for efficient inverted index queries and update locality
  • Kafka as a CDC pipeline streaming product catalog changes to Elasticsearch indexers for near real-time indexing under 1 minute
  • RESTful API with POST /search supporting JSON filter DSL, GET /facets for facet metadata, and GET /refresh-token for cache invalidation
  • TLS 1.3 for all network communication and AWS KMS-managed encrypted snapshots for data at rest encryption in Elasticsearch
  • Stateless API servers behind autoscaling load balancers and Elasticsearch clusters with shard replication and cross-cluster replication for HA
  • Blue-green deployment strategy with health checks to enable zero downtime during system upgrades
  • Pagination and cursor-based tokens in search API to support efficient deep paging and consistent results
  • Filter DSL supporting boolean operators and multi-dimensional filters to enable complex user queries

Practice

(1/5)
1. In the recommendation system request flow, at Step 4 the Embedding Service receives a user rating event from Kafka. What does it do if the user embedding is not found in the cache?
easy
A. It returns an error to the user indicating embedding missing
B. It fetches the embedding from persistent storage and updates the cache
C. It ignores the event and waits for the next rating update
D. It recomputes the embedding synchronously before processing the event

Solution

  1. Step 1: Trace Embedding Service behavior at Step 4

    When cache miss occurs, the service must retrieve embedding from persistent storage to maintain consistency.

  2. Step 2: Evaluate options

    Returning error (A) breaks user experience; ignoring event (C) loses data; synchronous recomputation (D) is expensive and blocks processing. Fetching from storage and updating cache (B) ensures availability and eventual consistency.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Cache miss triggers fetch from storage and cache update [check]
Hint: Cache miss -> fetch from storage and update cache [check]
Common Mistakes:
2. A customer support bot must handle 10,000 concurrent user queries with minimal latency and ensure fallback to human agents when intent classification confidence is low. Which component is best suited to manage the fallback routing reliably?
easy
A. A relational database storing fallback requests synchronously
B. An in-memory cache storing fallback intents temporarily
C. A REST API endpoint directly invoking human agent notification
D. A message queue system decoupling intent classification from fallback processing

Solution

  1. Step 1: Identify fallback routing requirements

    The fallback must be reliable and decoupled from real-time intent classification to avoid blocking user queries.

  2. Step 2: Evaluate component suitability

    A message queue decouples processing, enabling asynchronous fallback handling and retry mechanisms. Relational DB synchronous writes (A) cause latency. REST API direct calls (C) block the main flow. In-memory cache (D) lacks durability and reliability.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Message queue decouples and buffers fallback reliably [check]
Hint: Decouple fallback with queues for async reliability [check]
Common Mistakes:
3. In a system trace, at Step 3 the Storage Estimator component calculates daily storage needs. If the average object size is 2MB and the system expects 500K new objects daily, what is the storage estimate at Step 3?
easy
A. Cannot estimate without knowing retention period
B. 1TB per day, calculated as 500K objects x 2MB each
C. 2TB per day, assuming 4MB average object size instead
D. 500GB per day, assuming 1MB average object size instead

Solution

  1. Step 1: Calculate daily storage

    Multiply 500,000 objects by 2MB each = 1,000,000 MB = 1TB per day.

  2. Step 2: Eliminate other options

    500GB per day, assuming 1MB average object size instead uses wrong object size; 2TB per day, assuming 4MB average object size instead doubles size incorrectly; Cannot estimate without knowing retention period ignores that retention affects total storage, not daily estimate.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    500K x 2MB = 1TB daily storage [check]
Hint: Daily storage = object count x average size [check]
Common Mistakes:
4. In a distributed tracing system, at step 4 the Trace Collector receives a span with a missing parent ID. What is the most likely state of the trace at this point?
easy
A. The trace is complete and ready for visualization
B. The span is treated as a root span, starting a new trace segment
C. The span is discarded because it cannot be linked to any trace
D. The span is buffered indefinitely until the parent span arrives

Solution

  1. Step 1: Understand how tracing handles missing parent IDs

    Spans without parent IDs are treated as root spans, starting new trace trees.

  2. Step 2: Eliminate other options

    Discarding spans loses data unnecessarily; buffering indefinitely risks memory leaks; trace completeness requires all spans, so it's not complete yet.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Missing parent ID -> new root span starts trace segment [check]
Hint: Missing parent ID means new root span [check]
Common Mistakes:
5. For computing ETA in a city with highly variable traffic, which approach is better and why?
medium
A. Use a precomputed route cache updated daily with average travel times
B. Use a static shortest path algorithm with fixed average speeds per road segment
C. Use a heuristic-based routing ignoring traffic but optimizing for shortest distance
D. Use a dynamic routing algorithm that incorporates live traffic data and historical patterns

Solution

  1. Step 1: Compare static vs dynamic ETA computation

    Static shortest path (A) and precomputed caches (D) ignore live traffic variability, leading to inaccurate ETAs.

  2. Step 2: Evaluate heuristic and dynamic approaches

    Heuristic ignoring traffic (C) fails in variable conditions; dynamic routing (B) adapts to live and historical data for accurate ETA.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Dynamic routing with live traffic yields accurate ETAs in variable conditions [check]
Hint: Dynamic routing adapts ETA to live traffic, static can't [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