Four factors decide how well a cache performs: its placement, data distribution, write policy and eviction policy.
The founder needs three large Redis instances for the t-shirts data. The code shows what is wrong:
- The most popular t-shirts are queried from the database every time, because the cache can become stale. Popularity does not need the latest data, so the cache expires after one hour or six hours.
- A user's recently viewed t-shirts are stored as heavy objects. Storing only the t-shirt IDs removes the duplicate information.
- A write policy keeps the cache consistent. Write-through updates the database first and then the cache. Write-behind updates the cache and writes to the database when the entry is evicted. That reduces the database load, but a Redis crash loses the updates.
- One entry per user grows with the users. The cache is fixed at a thousand entries, and an eviction policy decides which entry is evicted: least recently used or least frequently used. Under least frequently used, hot data takes a long time to reach the cache.