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 ?
  • As I am not expierenced in such scenarios, I only add my thoughts in a comment instead of providing a real answer. To (1):The better caches you have, the faster is the lookup. So construction in advance should be better. Perhaps a product like elastic.co/de/products/elasticsearch which is specialized on searching is of any help. (2) step 6 relies on caching and may be faster. (3) I do not know. Apr 22, 2017 at 8:33

3 Answers 3


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.

  • when you say replication is much simpler than sharding do you mean master slave model where updates happen on one server while read from slaves ? Also in ` but run them on your front end server.` what is front end server you are referring here ? Apr 22, 2017 at 13:42
  • Yes. A system like you describe should have far fewer writes than reads, so can be scaled to a reasonable degree by distributing the reads but count writes to all servers. Particularly if you can allow for batched updates. As to front end, what I was trying to say was to run your caches in the same physical machine they will be used from, as this reduces latency and network usage.
    – Jules
    Apr 22, 2017 at 15:59
  • Regarding your statement 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, say my client expect there is a good possibility that system can scale up to the level of amazon with in a year. My point is then why not design it that way upfront even if it takes some time more to develop otherwise website will fetch bad publicity becoz of latency ? Apr 22, 2017 at 23:55
  • If your client expects to scale to the size of Amazon within a year, your client is being hopelessly optimistic. As a consultant, I'd say the important thing is to make sure they understand this, and that you can design a system where scalability can be added later, and that by far the most likely outcome of delaying a launch to make their system scalable from the beginning is that they lose the revenue they would have had while waiting to build features they don't need.
    – Jules
    Apr 23, 2017 at 9:32

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.


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.

  • Thanks mcottle. First of all RDBMS does not cahe query results(see stackoverflow.com/questions/3084789/…). Also sharding DB's provides load distribution which is very cumbersome. If application is of scale like amazon , we need to think premature scalability proactively, I believe. 2. Second when you say very prone to poor performance, and resistent to most mainstream tuning strategies. can you please elaborate why you think its prone to poor performance and resistant to tuning strategies ? Mar 24, 2017 at 1:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.