Before diving into Reliability - we need to understand the principles and make sure they are correctly applied.
Premature Optimization is the root of all evil -- Donald Knuth (The Art of Computer Programming)
A similar problem comes with relibaility design - where complexity exponentially increases with diminishing returns - which you may not even need.
So what do we need to know?
Everyone wants their applications to be highly available - but reliability is subjective, and often a Service Level Agreement - one of the primary instruments of reliability - talks more to fiscal compensation than design principles. So when you design the SLA - first work to understand two items:
RPO - Recovery Point Objective. How old can data in the event of an outage?
RTO - Recovery Time Objective. How long between outage and recovery is acceptable?
Shertil, Mahmud. (2016). TRADITIONAL RDBMS TO NOSQL DATABASE: NEW ERA OF DATABASES FOR BIG DATA.
It's tempting to say: 'zero and zero'. Much like CAP Therom covers Consistency, Availability, and Partition Tolerance, there are trade offs between Effort Cost, Infrastructure Cost, and Availability.
With these two parameters we start to get closer to SLAs that align to the realities of our business, and we can then design infrastructures with appropriate levels of complexity.
