That pretty much describes iCloud.
Argh! Zombies!
iCloud has terrible syncing. Here’s an example. Synced bookmarks in Safari:
I use three devices, regularly; my laptop (really a desktop, most of the time), my iPad (I’m on it, now), and my iPhone.
On any one of these devices, I may choose to “favorite” a page, and add it to a fairly extensive hierarchy of bookmarks, that I prefer to keep in a Bookmarks Bar.
Each folder can have a lot of bookmarks. Most are ones that I hardly ever need to use, and I generally access them via a search.
I like to keep the “active” ones at the top of the folder. This is especially important for my iPhone, which has an extremely limited screen (it’s an iPhone 13 Mini -Alas, poor Mini. I knew him well).
The damn bookmarks keep changing order. If I drag one to the top of the menu, I do that, because it’s the most important one, and I don’t want to scroll the screen.
The issue is that the order of bookmarks changes, between devices. In fact, I just noticed that a bookmark that I dragged to the top of one of my folders, yesterday, is now back down, several notches.
Don’t get me started on deleting contacts, or syncing Messages.
I assume that this is a symptom of DB dysfunction.
Otherwise it's far more likely to be faulty sync algorithm.
If you are selecting at ONE then yes, you can expect stale replies if you contact a different node. That is what the consistency level means; that just one node has seen the write.
The other behaviour you’re talking about is hinted handoff.
“So much fun to maintain” -> cassandra has very specific use cases. And hosted versions exist.
Disclosure: I work at Aiven, which has an hosted cassandra offer.
If you have 3 and you for CL 3 instead of quorum, and only 2 are up, it won’t partially write - it’ll throw an unavailable exception instead of attempting it
If you have 3 and specify quorum and 1 is down, it’ll write to the two, and propagate to the third in one of three ways:
- via hints (the timed thing you describe),
- via active repair (times and tombstones don’t matter at all, and data can’t magically come back to life with reasonable config settings), or
- or via read repair when you read from a quorum that overlaps the down node, again, regardless of pretty much anything else, this always happens.
https://cassandra.apache.org/_/blog/The-Path-to-Green-CI.htm...
https://cassandra.apache.org/_/blog/Finding-Bugs-in-Cassandr...
https://cassandra.apache.org/_/blog/Testing-Apache-Cassandra...
https://cassandra.apache.org/_/blog/Introducing-Apache-Cassa...
it mostly work but it’s extremely slow and still have many bugs.
https://www.datastax.com/blog/lightweight-transactions-cassa...
Until recently they were indeed slow over the WAN, and they remain slow under heavy contention. They are now faster than peer features for WAN reads.
However, the claim that they have many bugs needs to be backed up. I just finished overhauling Paxos in Cassandra and it is now one of the most thoroughly tested distributed consensus implementations around.
LWT still have awful performance compared to a write request with same guarantee in any other database.
https://thenewstack.io/an-apache-cassandra-breakthrough-acid...
A prototype has been developed that has demonstrated its correctness against Jepsen.io’s Maelstrom tool
Unless the node was down too much and could not fully catch up before a set time (DB TTL if I remember correctly), in which case the data might be propagated or not, and old deleted data might come up again and be repropagated by a cluster repair.
So much fun to maintain