What I meant is that beat effort consistency can be super naive or can try hard, even without guaranteeing it, to avoid losing data in certain failure modes.

> If a sysadmin uses an RDBMS with relaxed fsync, they know what they are getting

Removing fsync is generally referred to as "running with scissors" mode, although postgres now supports it better with unlogged tables.

Building computer systems / architectures is always about compromises. If your requirements are that "everything must be perfect always", you will never deliver anything.

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.

ACID guarantees feel like they can be distilled to "everything must be perfect always" - and you can ensure ACID and still ship, just by using an ACID database. It's a hard problem, but it's also a solved problem.

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.

I guess it's almost like speaking two different languages when talking about what a DB guarantees and what your application REQUIRES in the form of guarantees. Typically, in my experience, they're not the same thing. Or not ALWAYS the same thing. Within the problem space you're trying to come up with a solution for, I'd say it's highly unlikely "ACID" guarantees are sufficient to say categorically (with 100% accuracy) that "my application is perfect because: ACID".

agree with you (computerGuru) at large scale any rare or corner case happen multiple time per day :-)

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.

> sysadmin

we live in the age of devOps. there's no such thing as sysadmin, or god forbid, DBAs.

/sarcasm

For real! Where did all those DBAs go??

They're charging $400 an hour to come in and unfuck years of devs thinking they can design databases because they read a MySQL How-to Article

They retired and since no millennial wants to work for an Oracle degree no new ones came in to the field /s

We gladly paid one 800 € for three hours of work.. fixing a botched stored procedure on IBM DB2. Gray haired DBAs with the right blend of dev, ops and most importantly business domain knowledge (something many people in IT seem to overlook) are worth gold

infrastructure as code == infrastructure by coders