The basic tradeoff of distributed system is that if you increase the number of write replicas that is needed to be updated for commitment, you improve reliability, but increase latency. On the flip side, if you want to reduce latency, you should reduce the amount of write replicas needed to reach consensus.
Distributed databases can be configured in many different ways. The most simplest way is probably single master, multiple slaves configuration. In a single master, multiple slaves configuration, you don't really have a distributed writes, all writes goes to the master, who is the final arbiter. The slaves, also known as read replicas, simply synchronises their data periodically (periodic replication) or sometimes in real time (streaming replication). The slaves only work as a read only replicas to distribute work for read-only queries and so they're usually allowed to be slightly out of date. So as long as all the necessary conditions are rechecked against the master database in the final commitment transaction, it's ok for the read/non commitment operations to work off read replicas. Single master-multiple slaves are very commonly used because they're simple to work with, you can mostly treat it just like non-distributed database.
Another common way is multi-master configuration. In a multi-master configuration, writes need to successfully pass certain threshold of the number of masters that committed the transaction, for the entire distributed transaction to reach a consensus. In a multi master configuration where the number of write replicas is less than the number of masters, reads in a transaction will actually also have to be distributed, each master may have to check with each other to find if another master have a newer copy of the data. In most cases, multi master setup generally degrades latency. Multi master configuration main advantage is to improve availability/reliability in case of data/machine loss, and not performance or scalability. Multi master configuration may also be used when there are multiple parties that want to co-operate but don't fully trust each other to maintain the golden copy, so each parties may hold their own master copy, and distributed consensus is required for the system to proceed with a transaction.
A third technique for distributed database is called sharding. Sharding is a technique where you have multiple master databases, but you only need to write to a single database server to reach commitment. Instead of trying to reach a distributed consensus, a sharded database distributes writes by deciding which database is considered as the master for the current operation by looking at the sharding key attribute of the operation (for example, if you use the flight number as sharding key and you have two masters, you may decide that all writes whose Flight number starts with A-M will be decided by Server A, and all writes for flight numbers that starts with N-Z will be decided by Server B). The drawback of sharded system is that you can't really have an operation that simultaneously requires commitments by data in different shards (that would require a consensus).
It's also possible to combine read replicas, multi-master, and sharding. In some circumstances, it's also possible to have a system that can elect one of the slaves to become a new master if the system lost a master. There are various considerations to make with such hybrid configurations, as they combine both the advantages and disadvantages of the schemes, so they need to be very carefully considered.
Which ones to use for your particular scenario depends on the precise reason you want to scale out.