Back to the basics: Caching Compression


Back to the basics: Caching Compression

I spend a lot of time talking about how you can save a lot of money by optimizing the virtual hardware that makes up your server infrastructure by using tools like Valkey and ElastiCache, but let's not overlook the basics, specifically compression.

Recently, I while I was researching my daily content, I came across a case study talking about how a decent sized streaming company used AWS Serverless Elasticache and Valkey to save 98% on their caching costs.

Yes, it did require a migration, but one of the major factors that is so basic it could get overlooked is that they used ZStandard to compress their JSON by a factor of roughly 2.896.

That means they only need to store just over ⅓ of the amount of bytes. Those bytes clearly added up to big savings. Not 98% of savings, I am sure, but 66% perhaps?

Additionally, there is the cost of data transfer between the application layer and the data layer. If for some reason, this data crosses AZs or regions that can add up quickly.

There are some trade-offs. You will add a few milliseconds when you compress the data, then every time that data gets read, you will need to decompress the data, which also adds more milliseconds of latency.

I am not telling you to use compression or not, just reminding you to do the math and see if the slight latency tradeoff is worth it.

It’s worth taking a look at to weigh out your options.

If you need help with something like this, feel free to reach out, and let's chat.