Search functionality design in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable search architecture for a large e-commerce platform

You need to design the search functionality for a large e-commerce platform with millions of products. Which architectural component is essential to ensure fast and relevant search results?

A A simple key-value store that stores product IDs only

B A relational database with complex SQL queries for every search request

C A distributed search index like Elasticsearch to handle full-text queries and ranking

D A batch job that updates search results once a day

💡 Hint

Think about how to handle fast text search and ranking at scale.

Distributed search indexes like Elasticsearch are designed for fast full-text search and relevance ranking, which is essential for large-scale e-commerce search.

❓ scaling

intermediate

Handling high query volume in search functionality

Your search service receives a sudden spike to 10,000 queries per second. Which approach best helps maintain low latency and high availability?

A Run all queries synchronously on a single server

B Increase the database connection timeout to handle more queries

C Disable search autocomplete to reduce load

D Implement caching of popular search queries and results at the edge

💡 Hint

Think about reducing repeated work for common queries.

Caching popular queries at the edge reduces load on the search backend and improves response times during traffic spikes.

❓ tradeoff

advanced

Choosing between real-time and batch indexing for search

Which tradeoff is true when choosing real-time indexing over batch indexing for search data?

A Real-time indexing provides fresher data but requires more resources and complexity

B Batch indexing is always faster and more resource-efficient than real-time indexing

C Real-time indexing eliminates the need for any data validation

D Batch indexing guarantees zero downtime during updates

💡 Hint

Consider freshness of data versus system complexity.

Real-time indexing updates search data immediately but needs more compute and complex pipelines, while batch indexing is simpler but less fresh.

❓ component

advanced

Key components of a search system architecture

Which component is NOT typically part of a modern search system architecture?

A Load balancer that distributes search requests across servers

B Relational database that stores raw images for search results

C Indexing pipeline that processes and stores searchable data

D Query parser that interprets user input and generates search queries

💡 Hint

Think about components directly related to search query processing and indexing.

Raw images are usually stored in object storage or CDN, not in relational databases as part of search architecture.

❓ estimation

expert

Estimating storage requirements for search index

You have 100 million documents averaging 1 KB each. Your search index expands data by 3x due to inverted indexes and metadata. Approximately how much storage do you need for the search index?

A Around 300 GB

B Around 30 GB

C Around 3 TB

D Around 1 TB

💡 Hint

Calculate base data size and multiply by expansion factor.

100 million docs * 1 KB = 100 GB base data. 3x expansion means 300 GB total index size approximately.

Practice

1. What is the main purpose of building an index in a search functionality system?

easy

A. To compress data for storage

B. To store user passwords securely

C. To display images faster on the screen

D. To quickly find data entries matching search keywords

Solution

1. Step 1: Understand the role of an index in search

   An index maps keywords to data entries, enabling fast lookup instead of scanning all data.

2. Step 2: Identify the correct purpose

   Since search needs to find matching data quickly, the index helps achieve this by direct access.

3. Final Answer:

   To quickly find data entries matching search keywords -> Option D

4. Quick Check:

   Index = Fast keyword lookup [OK]

Hint: Index means fast lookup, not storage or compression [OK]

Common Mistakes:

• Confusing index with data compression
• Thinking index stores passwords
• Assuming index speeds up image display

2. Which data structure is commonly used to implement a search index for keyword lookup?

easy

A. Hash map

B. Linked list

C. Stack

D. Queue

Solution

1. Step 1: Recall common data structures for fast lookup

   Hash maps provide average O(1) time for key-based access, ideal for mapping keywords to data.

2. Step 2: Eliminate other options

   Linked lists, stacks, and queues do not provide efficient direct lookup by key.

3. Final Answer:

   Hash map -> Option A

4. Quick Check:

   Hash map = Fast key lookup [OK]

Hint: Hash maps give fast key-based access, perfect for indexes [OK]

Common Mistakes:

• Choosing linked list which is slow for lookup
• Confusing stack or queue with key-value storage
• Ignoring average O(1) lookup time of hash maps

3. Consider a search system where the index maps keywords to document IDs. If the keyword 'apple' maps to [1, 3, 5] and 'banana' maps to [2, 3], what is the result of searching for documents containing both 'apple' and 'banana'?

medium

A. [1, 2, 3, 5]

B. [3]

C. [1, 5]

D. [2, 3, 5]

Solution

1. Step 1: Identify documents for each keyword

   'apple' maps to documents [1, 3, 5], 'banana' maps to [2, 3].

2. Step 2: Find intersection of document lists

   Documents containing both keywords are in both lists. Intersection of [1, 3, 5] and [2, 3] is [3].

3. Final Answer:

   [3] -> Option B

4. Quick Check:

   Intersection = [3] [OK]

Hint: Search AND means intersection of document lists [OK]

Common Mistakes:

• Merging lists instead of intersecting
• Confusing union with intersection
• Ignoring common documents

4. A search system uses a hash map to store keyword to document ID mappings. The code snippet below has a bug:

index = {}
keywords = ['apple', 'banana', 'apple']
docs = [1, 2, 3]
for i in range(len(keywords)):
    index[keywords[i]] = docs[i]
print(index)

What is the bug in this code?

medium

A. It overwrites previous document IDs for duplicate keywords

B. It uses a list instead of a dictionary

C. It does not initialize the index

D. It uses wrong loop range

Solution

1. Step 1: Analyze how index is updated

   The loop assigns index[keyword] = doc, so duplicate keywords overwrite previous values.

2. Step 2: Identify the bug

   For 'apple', first doc 1 is stored, then overwritten by doc 3, losing doc 1.

3. Final Answer:

   It overwrites previous document IDs for duplicate keywords -> Option A

4. Quick Check:

   Duplicate keys overwrite values in hash map [OK]

Hint: Duplicate keys overwrite values unless stored as list [OK]

Common Mistakes:

• Thinking loop range is wrong
• Assuming index is not initialized
• Confusing data structure type

5. You are designing a search system for a large online store with millions of products. To support fast search by keywords and handle high user traffic, which combination of design choices is best?

hard

A. Use a simple list of products and filter by keywords on the client side

B. Store all product data in a single SQL table and scan it for each search

C. Use an inverted index stored in a distributed NoSQL database with caching layers

D. Build an index only for the top 10 products and search others sequentially

Solution

1. Step 1: Consider scalability and speed needs

   Millions of products and high traffic require fast, scalable search with distributed storage and caching.

2. Step 2: Evaluate options

   Use an inverted index stored in a distributed NoSQL database with caching layers uses inverted index (fast keyword lookup), distributed NoSQL (scalable), and caching (speed). Others are slow or incomplete.

3. Final Answer:

   Use an inverted index stored in a distributed NoSQL database with caching layers -> Option C

4. Quick Check:

   Inverted index + distributed storage + cache = scalable fast search [OK]

Hint: Combine inverted index, distributed DB, and cache for scale [OK]

Common Mistakes:

• Choosing full table scan for large data
• Filtering on client side for millions of items
• Indexing only a small subset of data