Learn Redis the hard way: in production
This comment may be a bit snarky, but it&#x27;s important to understand that the TL;DR for this is not: you need to learn how to debug Redis and understand a lot of internal things about it and the libraries using it. It&#x27;s that you can really save yourself a ton of time and headache with a better understanding of application architecture.<p>Step 1) Throw everything at Redis because you don&#x27;t know how to architect. Use it as a cache. Use it as a temporary data store. And use it as a persistent data store <i>at the same time.</i> What could go wrong, right?<p>Step 2) Watch it break because you&#x27;re using it wrong.<p>Step 3) Write a blog post about everything you discovered about how you can sort of get it working while continuing to do it wrong.<p>Step 4) Only concede at the very end of the blog post that you were just <i>doing it wrong™</i> from the beginning.<p>&quot;The root causes of these errors were more a conceptional[sic] issue. The way we used Redis was not ideal for this kind of traffic and growth.&quot;<p>Unless I&#x27;m missing something, there&#x27;s really no reason that all three use cases (caching, temporary data store, persistent data store) should all be sitting on a single Redis server so far away from the metal of the application server.<p>I do not want my search cache waiting on temporary data to be read and flushed from the cache. I do not want data I&#x27;d like to persist competing with search cache results. I don&#x27;t want any of these things! That&#x27;s not how this works. That&#x27;s not how any of this works!