Product search design in ecommerce application?

Question

I am trying to come out with high level architecture for product search in big scalable ecommerce application like amazon/best buy etc.

Use case :- Search any item in free text. Say user search product "galaxy white" , it can be mobile phone, air condition, garment brand , beaty product etc. I need to display all products in page. Just leave ranking product out of scope for now.

Design data points:-

1. There will be sharded database with each shard containg particular product category.
2. Similarly there will be distributed cache servers (may be redis or memcached) where each server will contain a specific product category data. for example one server can contain mobile data with key as brand name and value as again map.This nested map will contain model as key and product detail as key. Product detail can further contain list of sellers etc.
3. We will also cached the Product_category_map which will contain most sought after product names as key and product categories as value list. It may be loaded on server startup and may be updated after some regular interval of time say 4 hours. For example :- Map will contain "galaxy" as key and value as {"Mobile", "garment"}
4. Now when user search for product "galaxy white", it will search for cached Product_category_map, if it finds there,it will get product categories name as value
5. If it is not found in step 4, parallel call(map reduce) will go to all sharded DB for fetching product category
6. Once product categories are found, it will fetch the all matching products from cache i.e. from respective cache server for each category and then apply further filtering like description/colour/other_attribute is white in this case.
7. Another alternative approach to step 6 can be , fetch matching products from sharded DB for each category. Here i can use DB index for filtering on white attribute

I want to confirm below points

1. Approach in point 3 . When user types some text, shoild I construct the Product_category_map cache in advance , fetch it from there . I am not sure whether it is good approach to cach all product name against their category or it should fetch the categories from sharded DB's( in parallel using framework like mapreduce)
2. Among 6/7 approach, which one is better ?
3. Is similar desgign used by any scalable ecommerce application ?

Answer 1

You are optimizing prematurely for facilities that will be extremely costly and which you almost certainly will not need. The only way a new ecommerce system requires the scalability and performance of Amazon's is if you're writing it as a direct replacement for Amazon's existing system. Otherwise, your system will be smaller (probably by multiple orders of magnitude) and run fewer transactions per second (likewise) for the foreseeable future.

Design what you need now, not what you think you may need a year or five down the line. But design it with an abstract interface, so if you need to change it, you can do so without worrying about got other parts of the system interact with ît. That is how you build a scalable system.

More specifically, don't start with a sharded design. Initially, a single database server should be more than adequate. If you find you need to scale it, replication is much simpler than sharding, so should be your first approach. Adding caches at the front end may help, but run them on your front end server... Distributed caches are less performant and unlikely to be necessary.

Answer 2

Have you looked into using an established search platform instead of an RDBMS for the customer's shop search?

For example Solr is open source and used by several companies and frameworks like Hybris in an e-commerce context. It supports concepts like synonyms, localized tokenization, stemming or fuzzy search out of the box which would take some effort to replicate with a RDBMS. It's also pretty simple to scale using mechanisms like replicas and sharding. It removes strain from your RDBMS which can then focus on keeping track of the operational product data.

Answer 3

It sounds very complicated, very prone to poor performance, and resistent to most mainstream tuning strategies.

Is there a reason why you wish to create a caching engine/strategy from scratch when any decent RDBMS includes one as standard? Inside an RDBMS being used primarily as a read source the most used data will be cached in memory within the first few minutes of operation after which it will remain available until it is no longer among the most used. Yes, you will have to do some work in SQL to have well designed queries that support system performance but this information is pretty well documented.

You can add more memory to the database server, add more processor cores, you can horizontally scale by adding mirrored database instances although you will find that one database instance can support a lot of app servers so you will need to hit massive volumes before this becomes neccessary. Taking this approach will also have the added benefit of avoiding premature optimisation. You can scale up by adding web servers, load balancers, caches and database servers as required and in reponse to real world issues rather than preemptively setting up an overly complicated and expensive architecture for a website that doesn't take off as hoped or if it does, ends up with issues in an area that you didn't anticipate.