thanks a lot! another great video! i have some confusion about data version based staleness judgement though. suppose we have two replicas, the first write was sucessful on replica one, the second write was successful one replice two. then we have both replicas with the same version, but different data. i suppose this could be fixed by process you mentioned to deal with read staleness, but i suppose it wont be real time, so wont exactly fix the issue. another possibility, we could compare with other replicas when we write, but it beats the idea of leaderless and writing to replicas independantly. so i dont know the fix.
I think short answer is, if you use DBs with such an architecture, you are inherently accepting the tradeoffs. If your application requires strong consistency, you should consider DBs that give stronger consistency guarantees.
Hi! Really appreciate the suggestion. I got that feedback before too, so there must be something to it. I will go ahead and remove it from future videos.
Even if the client reads data from X nodes and returns the latest data, that data may not be the latest because you only need X acknowledgements. By chance, all X replica nodes may not have the latest data. But your data will be eventually consistent after sufficient number of reads.
