The load shifting part is similar to the way BigTable splits, merges, and assigns tablets. But the rest of it is not related, because BigTable does not try to offer mutation consistency across replicas. If you write to one replica of a BigTable, your mutation may be read at some other replica, after an undefined delay. Applications that need stronger consistency features must layer their own replication scheme atop BigTable (such as Megastore).

What this post is describing for replication seems more comparable to Spanner.

"can i copy your homework" "yeah but change it a bit" (compared to the other comment that looks nearly identical, looks lik yugabyte sent some people in here)

I thought of the same thing, so I am trying to find information on the documentation about things that CockroachDB does very well:

1. Consistent backups/transactions. When a backup is made, is that a single point in time, or best-effort by individual tablet. For example, backing up an inventory and orders table, the backup could have an older version of inventory, where orders have already been completed for some of them. It looks like Scylla backsup per node, so it could mean that data might have a slight time offset from one another.

2. Replicate reads. Like CockroachDB, it looks like Scylla will redirect the read to the range lead, but CRDB also provides the option to get stale reads from a non-lead. This is usually good for cross-region databases where reading off the lead can be big increases in latency.

I do not have a lot of time, but I am having a hard time finding much information about the architecture on Scylla's documentation. My personal guess is that Scylla optimized their code for performance, and less worry about data integrity.

How so? Mind saying more?