Search functionality design in LLD - System Design Guide

Problem Statement

Users expect to find relevant information quickly, but a naive search that scans all data sequentially causes slow responses and poor user experience. As data grows, search queries become slower and less scalable, leading to timeouts and frustrated users.

Solution

Search functionality design uses indexing and optimized query processing to quickly locate relevant data without scanning everything. It builds data structures like inverted indexes to map keywords to documents, enabling fast lookups and ranking results by relevance.

Architecture

User Query

→Search Service

↓

Ranking &

Result Sort

This diagram shows a user query sent to the search service, which consults the index store to find matching documents. The results are ranked and sorted before returning to the user.

Trade-offs

✓ Pros

→

Significantly faster search responses by avoiding full data scans.

→

Scalable to large datasets by using efficient indexes.

→

Improves user experience with relevant, ranked results.

→

Supports complex queries like phrase search and filters.

✗ Cons

→

Index building and updating adds complexity and resource use.

→

Requires careful handling of index consistency with data changes.

→

Ranking algorithms can be complex and require tuning.

When the dataset exceeds tens of thousands of records and users require fast, relevant search results with complex query support.

For very small datasets under a few thousand records where full scans are fast enough and index maintenance overhead is unnecessary.

Real World Examples

Amazon

Uses inverted indexes and ranking algorithms to quickly find relevant products from millions of listings based on user search queries.

Google

Builds massive distributed indexes to serve billions of search queries per day with low latency and high relevance.

Airbnb

Implements search with filters and ranking to help users find suitable listings quickly from a large inventory.

Code Example

The before code scans every document for the query word, which is slow for many documents. The after code builds an inverted index mapping words to documents, enabling fast lookup by intersecting sets of documents containing each query word.

LLD

### Before: Naive search scanning all documents
class SearchEngine:
    def __init__(self, documents):
        self.documents = documents

    def search(self, query):
        results = []
        for doc_id, text in self.documents.items():
            if query.lower() in text.lower():
                results.append(doc_id)
        return results


### After: Using inverted index for fast lookup
class SearchEngine:
    def __init__(self, documents):
        self.documents = documents
        self.index = self.build_index(documents)

    def build_index(self, documents):
        index = {}
        for doc_id, text in documents.items():
            for word in text.lower().split():
                index.setdefault(word, set()).add(doc_id)
        return index

    def search(self, query):
        query_words = query.lower().split()
        if not query_words:
            return []
        result_sets = [self.index.get(word, set()) for word in query_words]
        # Intersection of sets to find docs containing all query words
        results = set.intersection(*result_sets) if result_sets else set()
        return list(results)

Alternatives

Full Table Scan

Scans all data sequentially without indexes, resulting in slower queries.

Use when: Dataset is very small or queries are infrequent and simple.

Database Text Search

Uses built-in database text search features, which may be less flexible or scalable than dedicated search engines.

Use when: When integration simplicity is more important than advanced search features.

Search as a Service (e.g., Algolia, Elasticsearch Cloud)

Outsources search infrastructure to managed services, reducing operational overhead.

Use when: When rapid development and maintenance reduction are priorities over full control.

Summary

Naive search scanning all data is slow and unscalable for large datasets.

Search functionality design uses indexes and ranking to deliver fast, relevant results.

Trade-offs include index maintenance complexity versus improved user experience.

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