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.
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)
So there is no performance penalty.