This document discusses Flipkart's search architecture and how it addresses challenges for e-commerce search. It has a diverse catalog of 13 million products across 900 categories. It needs high performance with 99.99% availability and 1000 queries per second. There are also high rates of updates. Solutions discussed include caching, external source fields for sorting/faceting/filtering, and relevance optimizations. Caching improves performance 10-50x by caching results. External fields help with updates and partitioning. Relevance is tuned using boosts, user feedback, and query classification.

1. Search @ Flipkart
Umesh Prasad
Thejus VM
Empowering Consumers discover and find products
Solr/ Lucene Meetup 2 @ Bangalore
Date : July 27, 2013

2. Outline
● Search Architecture @ Flipkart
● Challenges for E-commerce
○ Diverse Catalogue
○ Availability, Uptime and performance
○ High frequency updates
● Solutions
○ Caching and warm up
○ External Source Fields (Sort, Facet, Filter)
○ Relevance optimizations

4. Flipkart Search Architecture

5. Technologies Used

6. The E-commerce Search Challenge
● Diverse catalogue
○ ~13 million products, ~900 categories
○ What fields to Search
○ How to rank (within category/across categories). Ranking Facets ?
○ tf-idf and vector space model doesn't help
● Performance
○ 99.99 % availability
○ ~1000 qps
○ ~75 ms for Search, ~5 ms for Autosuggest
○ Prefetching data (Conflicts with liveliness)
● High rate of updates
○ Multiple data sources (aggregate, index, commit, replicate)
○ Temporal fields (Price/Availability/SLAs/Offers)
○ Lucene doesn't support partial updates

7. Addressing - Performance / Latency
● Make Search Faster
○ Use Filters, score only if needed, lazy field loads,
smaller indexes aka sharding
● Caching
○ Solr caches (Type/Sizing/Tuning/Warming)
○ Custom caches
○ Cache warmup on replication and startup

8. Solr Search Flow
And High Latency Cache
Cache hit is 10X -
50X faster.

9. Solr Caches
● QueryCache
○ Key = <Lucene Query, Filters, SortFields>
○ Value = Docset(Bitset) / DocList (bitset with score)
○ Caching only a results Window
○ Use : Pagination/repeat queries
● FilterCache
○ Key = Query
○ Value = Docset (maxDoc)
○ Matching / Faceting
● FieldValueCache
○ Key = FieldName
○ Value = <Term,DocSet>
○ Faceting
● DocumentCache
○ Key = docId
○ Value = Fields

10. Expensive Features
● Facet on Queries
○ Facet.queries
● Grouping
○ ngroups (counting number of groups )
○ facet counting of groups (makes 2nd query)
○ No Cache for Group
● Solution : High Latency Cache
○ Key = All Request Params
○ Value = Full response object
○ Re-generate

11. How replication Impacts Caching ?

12. Challenge 3 : High Rate of Updates
● Two Solutions
○ Near real time Indexing / Searching
○ External Fields
● NRT Indexing and searching
○ Softcommits => solr caches invalidated
○ Lot of churn : Document deleted and re-added.
○ No autowarm for document cache
● External Fields
○ Resonates with Horizontal partition (Document level
partitioning)
○ Great for Ephemeral fields (Price/availability/slas)
○ Supports faceting / filter / sorting

13. External Fields and Relevance Tuning

14. Sorting on 500 plus Dynamic Fields
● 10 million products * 4 bytes = 38.1 MB
● 38.1 MB * 500 fields = 17.0 GB of Heap Memory
● On replication : 17 * 2 = 34 GB Heap for just FieldCache
BOOM

15. External Fields

16. Relevance and Scoring
● Search Page(Query based scoring)
○ Handcrafted boosts to capture retail specific signals
○ User feedback based ranking
○ Turn off - query norm, tf, idf on specific fields
● Browse Page(Non Query based Scoring)
○ Challenge - How do we rank in order to maximize
diversity and still show relevant products

17. Query Classification
● Rank category for a given query
● Signals
○ Text Scoring
○ Retail signals
○ Click stream data
● Rules Specified over classifications for better
customer experience

18. Q & A