> And this most of the times does not happen too.
This rubs me very very wrong. There is no maybe in data integrity. Redis wasn’t designed to be ACID and shouldn’t be treated as such just because “usually” it doesn’t lose data “under the right circumstances.”
If a sysadmin uses an RDBMS with relaxed fsync, they know what they are getting (and durable writes is not one of them, no usually about it). Same for Redis.
Removing fsync is generally referred to as "running with scissors" mode, although postgres now supports it better with unlogged tables.
I came up with a "mental framework" that allowed me to get beyond these details early when I started architecting systems for companies.
1) Identify what are the possible malfunctions
2) What mechanisms will I use to detect these malfunctions as early as possible
3) Do I have a clear and concise recovery path for said malfunctions.
This frame of thought has taken me far (in terms of being able to accomplish a lot in my career so far) and allowed me to move forward without (a) extensive, time-consuming, research into the specific tools I'm using into the specific situations which may never happen, (b) extensive costs hiring experts in these niche areas.
Sometimes you don't need ACID guarantees, which is part of the reason databases like Redis exist, and is why the compromises you're describing are important. But in this context it sounds like the framework you're describing would lead to rolling your own ACID for Redis instead of just using an ACID database to begin with.
Redis was never designed for strong Synchronous replication of transaction or Strong leader election.
So each time a master crash you have a high chance of some recent acknowledged write being lost.
we live in the age of devOps. there's no such thing as sysadmin, or god forbid, DBAs.
/sarcasm