The dynamic Redis cache.

In the first post on the topic of Redis cache, I said that the only question to answer was whether your data requests followed a normal distribution or a linear one.

But that’s not really true.

Imagine again that you are the health care provider with the iPad app. And you are requesting information about a patient that you will see only once today. Like all your patients, they have a single appointment, and you’ll see them once. You may have two or three iPads that are held by your physician assistants and yourself. But that is the max number. So your requests for information about any given patient are limited. One, or two, or three. Maybe.

There are, however, three other physicians in your office requesting information through the same app about their own patients.

And there are 14 other offices in the metropolitan area that are in your group, and accessing the same database. And you are all plastic surgeons so no small percentage of the data is images.

So there are LOTS of requests going on. And there are a LOT of images being requested.

And — dammit — all the requests are unique. Or nearly all of them.

So, yeah, you should consider a redis cache anyway. And put all the image thumbnails in the cache. Not the full size images. The thumbnails are the bottleneck anyway. You walk in, open the app, open the patient and download ALL the thumbnails. Just like 2 or 3 or 30 or your collegues. All of whom have appointments at the top and bottom of the hour. All of whom have appointments at 1PM, right after lunch. Exactly like you.

In your case, the speed advantage will come if you have a broad cache, with lots of memory, to store thousands of (small, thumbnail-sized) images. And even though you don’t need them often, when you do, they are quickly available in an environment of high demand.

When the user wants a full size image, they tap on the thumbnail and make a new request anyway. THAT request doesn’t need the redis cache. And even the user perceives that a larger image is desired, so a larger lag in the response is tolerated.

There is a complication you’ll need to solve. The cache of thumbnails needs to be updated. Thumbnails themselves need to be generated from the original image. The original image needs to be uploaded from — presumably — the iPad camera or some other device. So your data store will need to update the cache. And even better, your cache will need to update the datastore.

Fortunately, implementing this in real life is easy. There are a number of commercial concerns to help you set up a dynamic redis cache. And in any case, it’s just a dictionary on a disk. When the data on the iPad changes, change the dictionary in the Redis cache. And when the data on the backend database changes, do the same.

In Azure you can create a cache resource. You can learn about this in Pluralsight. Microsoft Azure Developer: Implementing Azure Cache |…Ad·https://www.pluralsight.com/

In AWS you can also create a cache resource. https://aws.amazon.com/free/database/?trk=83add82a-8e52-4837-bc73-c323da62d78c&sc_channel=ps&s_kwcid=AL!4422!3!610000101570!p!!g!!amazon%20redis&ef_id=Cj0KCQjwpeaYBhDXARIsAEzItbFBIcrM8inLvYximJP7r0UoR3ata6r2k8QuxvuWOYWKeVuJmOM4-zgaAgIJEALw_wcB:G:s&s_kwcid=AL!4422!3!610000101570!p!!g!!amazon%20redis

In other environments, you can get help from redis.com, or check out the book by Atchison: Caching at Scale with Redis – Free eBook From Lee AtchisonAd·https://www.redis.com/

.