> What replica sets using Paxos and Raft propose is that you will literally deal with one master server and try to keep backup copies of an entire database aligned independently. When a master dies or fails, the clients try to decide on a new leader so that they are all talking to the same server. This leads to a delay in which no one can write.
No comment on Raft, but "a master" only exists in Paxos if you invent one. Any client can talk to any Proposer (which will then try to reach a quorum of Acceptors & Learners). Losing just one Paxos node will not result in a partition, so you can still operate happily with availability and consistency.
> There's no particular need to replicate a whole database if we only want to share a few records. Granularity is the answer to scalability and reliability.
Lots of data, lots of CAP tradeoff. Not much data, not much CAP tradeoff.
> In IT, correct values are assumed to be the latest values. It’s a race to be last, because the last value wins by overwriting and obliterating what came before. So if you have an evil demon flooding the system with nonsense, you’re in trouble.
Paxos itself does not allow for overwriting of values (Learners do not change their mind about the value of a given key.) In order for 'obliteration' to occur, you need to augment your key with a version number or timestamp - something that a downstream system could interpret to mean as "happened after".