Anywhere Cache and Rapid Storage share some infrastructure inside of GCS and both are good solutions for improving GCS performance, but Anywhere Cache is an SSD cache in front of the normal buckets while Rapid Storage is a new type of bucket.
Anywhere Cache shines in front of a multi-regional bucket. Once the data is cached, there's no egress charges and there's much better latency. This is great for someone who looks for spot compute capacity to run computations anywhere in the multi-region. It will also improve performance in front of regional buckets but as a cache, you'll see the difference between hits and misses.
Rapid Storage will have all of your data local and fast, including writes. It also adds the ability to have fast durable appends, which is something you can't get from the standard buckets.
Many enterprise storage systems have the durability/availability tradeoff like these replicated disks when replicating outside of a single datacenter. (Oracle calls it "max availability": try to synchronously replicate, but if the remote side is offline, allow transactions to commit.) Real world banks run on these sorts of systems.
Users don't continuously check replication status. They rely on it being synchronous almost all the time.
3 way quorum replication is great, but you then need to send to more data centers, potentially affecting performance. There's a tradeoff.
Regional Persistent Disk was in beta in 2019. Usability hiccups and other annoyances meant it only GA'd in 2023, but it's been used under CloudSQL for quite a while.
std::quick_exit() also works, though you can decide if it's worthwhile to allow parts of the program to register functions to be called at quick exit time.
If you can't afford stale reads then you should ask Etcd to wait for confirmation from the majority of followers before acknowledging a read with ?quorum=true. It makes Etcd do 1 round trip for reads (just like Gryadka).
The same is applicable to other products (you can't relay on time in distributed systems, unless you're Google, consequently you can't relay on read leases)
etcd didn't implement leases; it just assumed that the last Raft election was still good.
You can elect a leader for a set period of time (say, 10 seconds) and serve strong reads for a lesser period of time (5 seconds) if you have reasonable assumptions of how good your local oscillators work and avoid jumps. If you don't trust your local clock to any level of accuracy, why do you trust your local CPU?
Making implicit assumptions about the environment is wrong.
An instance may be running in virtual environment where time freezes are possible. A human may make an error and rollback time to 1970.
It's impossible to eliminate all these factors so yes I don't trust time but I trust CPU.
Maybe CockroachDB is doing it correctly but the terrible default settings make this optimisation negligible because when the leader dies the system hangs for 12 seconds.
(I work on Google storage)