Yugabytedb is a distributed rdbms. It uses data redundancy. How does it keep a good performance while having to keep multiple copies up to date?
Reads go to the raft leader and writes as well but wait for the quorum. So it depends on the topology. A Replication Factor RF=3 on one AWS region, for example, doesn't suffer as latency between AZs is low. For cross-region distribution, this is addressed with placement preferences. Like having all leaders near the users, and one nearby region will answer the quorum. Those preferences can be mapped to business info (like customer's country) through PostgreSQL partitioning and tablespaces