5 ms·
When I'm thinking about data stores in large systems I like to break them down depending on how they are used on two main axes: is it fast/slow moving and durab
by gav 6y ago
When I'm thinking about data stores in large systems I like to break them down depending on how they are used on two main axes: is it fast/slow moving and durability from "we don't care" and "we must never lose data".
It's easier to reason about systems if there's fewer things that require durability guarantees, ideally you want to be able to draw data flows that look like a tree instead of a graph.
I find that Redis fits great because it's perfect for a whole bunch of different temporal shared state needs, everything from sessions to partial results. I've also deployed things like Ehcache, MongoDB, and Memcached to fit these needs and found other tools such as Kafka or RabbitMQ to be great "glue".
Having the root of your important data be something "boring" like Postgres or MySQL (or even Oracle!) is just good risk management to me. I wouldn't want to trust Redis or MongoDB for important data because it adds to the things I have to worry about. It's "keeping your eggs in one basket" while making sure that basket is really well looked after.