Thread by @arcnotes

A deep technical dive into all things Redis. Covering various Redis topologies, data persistence and process forking.

Redis redis.io (“REmote DIctionary Service”) is an open-source key-value database server.

The most accurate description of Redis is that it's a data structure server. This specific nature of Redis has led to much of its popularity and adoption amongst developers.

Primarily, Redis is an in-memory database used as a cache in front of another "real" database like MySQL or PostgreSQL to help improve application performance. It leverages the speed of memory and alleviates load off the central application database

There are several ways to deploy Redis which one you go with highly depends on scale and use case. For simple deployments a single node cluster is all you need. For more complicated and mission critical workloads you might want Redis Sentinel.

Many have thought about what happens when you can't store all your data in memory on one machine. Currently, the maximum RAM available in a single server is 24TIB, presently listed online at AWS. Granted, that's a lot, but for some systems, that isn't enough. Thus Redis Cluster.

If we are going to use Redis to store any kind of data for safe keeping, it's important to understand how Redis is doing it. There are many usecases where if you were to lose the data Redis is storing is not the end of the world.

This coolest part of Redis in my opinion is how it leverages forking and copy-on-write to facilitate data persistence performantly. When you fork a process, the parent and child share memory, and in that child process Redis begins the snapshotting (Redis) process.

Redis Explained architecturenotes.co/redis/

I hope you've found this thread helpful.

Follow me @arcnotes for more.

Like/Retweet the first tweet below if you can:

Enjoyed this thread?

Follow @arcnotes and sign up at architecturenotes.co