Do you want users to be able to search your data? Let’s assume your database is a relational database. Pretty quickly it starts slowing down as your traffic grows and your queries get more complex. You could start caching your results in a value key store to take some load off of the DB, but you want to expire those caches occasionally so they repopulate with the latest changes from the database.

I would NOT recommend doing it this way for the following reasons: Eventually when those caches expire a lot of traffic will hit the DB in a way you are not expecting. Additionally if you are crawled by something quickly those expiration TTLs will line up and all expire around the same time causing a repeating window when the cache no longer exists and needs to be repopulated.

Instead what I recommend is, when the record is modified add it to a pre-built cache right after the DB record is modified. This means if a new product for your ecommerce comes in and it is the color “Red” right after the new product record is saved to the database you add a reference to that product id to your index that contains all the “red” product ids.

This absolutely works best with an event driven architecture as your worker would process the event broadcasted from your application when the event is modified and goes about updating all of the relevant indexes. If you are doing this without a background worker while the user is waiting for a response for their request they could be waiting sometime while you update all the relevant indexes.

One last added bonus for when you want to horizontally scale: It is pretty easy to shard Redis because there is only one possible shard key.

If you want to learn more about this in a lot more detail download my free e-book 20 Things You Can Do Today To Save Money On Your Amazon Web Services Bill