The second thing to know about a Redis cache.

The second thing to know about a Redis cache isn’t really about the redis cache. It’s about something called distributed context. This refers to the information held about you across the web.

But let me digress. I briefly wanted a Playstation 5. And part of the reason was that I was fascinated by how Amazon or Target or GameStop or BestBuy sell them. Imagine the problem: Each of these vendors is online. Each of them receives a handful of physical devices for resale. And in 2021 and 2022, during the pandemic, there was a rush for gaming systems. We know it started with Nintendo and Animal Crossing. And this demand bled into Playstation 5, but the availability of Playstation 5 was so low, that it was mostly ignored.

Except when it wasn’t. Except when there actually were a few units for sale at retail pricing. So, again, imagine the problem. Imagine that you are in the United States. And you are the network administrator for Amazon. The company has received a shipment of 500 units to San Diego. The units are then shipped to 5 sites across three time zones. 100 units at each of the 5 locations.

Now change your point of reference. Now you are a user. You have a Playstation 5 in your wish list. You have an Xbox series s in your shopping cart, and you’ve had it there for a day. Because it’s widely available and you and everyone else knows it. And you also have programmable Govee LED lights in your cart. You can’t put a Playstation 5 in your cart, because there’s no stock available. But you have it in your wish list. This is your context. It’s distributed and whether you know it or not, your context is affecting other Amazon shoppers. You have an Xbox in your shopping cart. So as long as Amazon allows you to keep it there, the total available stock of the Xbox series s is decreased by one. If enough other users were to suddenly want all the available stock of Xbox series s machines, your shopping cart item (your distributed context) would prevent one person from getting their prize. And you don’t know it, but you have the last Govee LED lights in your cart.

Now imagine that the scenario takes a dramatic turn. The rumor mill has said that Amazon, Target and BestBuy are each getting shipments of Playstation 5 at 6 AM tomorrow. This actually happened. What does Amazon do? How will they handle the onslaught of demand at 6AM. There are likely to be between 10,000 and 100,000 users each trying to buy one of the 100 units available in the Amazon distribution center nearest to them.

One answer is likely to be a Redis cache. The Redis cache will represent a single point of truth. That single point will contain the data that says how many units are available, and how many have been purchased.

From the user’s point of view, they know the Playstation is in stock. They try to add it to their shopping cart and make that request. Because it’s a High Demand item, Amazon routes their request to the single Redis cache. For a brief period around 6 AM all Playstation 5 requests don’t get routed the normal way. They go instead to the Redis Cache. The Redis cache says how many items of stock are still available. And it does so one at a time. It handles each request sequentially. So each request is handled with fidelity. If the request comes in while there are 30 out of 100 items available, then an item goes into the shopping cart of the requester. If the request comes in 1 or 2 seconds later, and there are 0 of 100 items available, then the Redis cache returns a ‘sold out’ response. And the cart remains empty of Playstation 5s.

The disadvantage in this case is that there are only 5 areas of the country where the Redis cache is operating. And if that Redis server is far away from you, you will never know it. You are dealing with a high latency in your request. You are possible just simply SOL. Amazon COULD weight every request with a latency penalty that is higher if they are closer to the server. That would be fair. I don’t know if they do.

This disadvantage in the single Redis cache-point-of-truth is the high latency. As Amazon, this is not the situation you want for common items. For common items you want to make the latency to purchase so small that it is not noticeable. And certainly not actionable. You want the user to make a purchase by touching the buy now button and then have the purchase finalized.

On the other hand, because you need to resolve the purchase of a high demand item at a single point, you’ll still want that server to respond as fast as possible. THAT is why you’ll use a Redis cache. You can’t help the latency — the distance between the purchaser and the Redis server. But you can do your best with the server response. So you hold all the data in volatile memory.

One last note: The stock count of the Playstation 5 is decreasing as purchases are made. The Redis cache is keeping track of this. This means the Redis cache can actually be used to keep track of dynamically changing data. That will be the subject of the third Redis entry here.