Replication. Do I understand correctly?

Question

PostgreSQL

In highload solutions, such a thing is often used: we write to master SQL (to which we only write) data from which is replicated to one or more slave SQL (from which we only read).
SQL (I use Postgresql) guarantees ACID where the letter "C" means Consistency - Consistency. Imagine the situation: there are servers "A" (master), "B" (slave) and "C" (slave). Two keys "X" and "Y" are atomically entered into the server "A" in the transaction. Further, these keys from server "A" should be replicated to servers "B" and "C". And they will be replicated atomically, both.
Suppose you are reading data: randomly select server "B" and read the key "X", randomly select server "C" and read the key "Y".
Question: is it possible that the keys "X" and "Y" are already replicated to the server "B", but not yet replicated to the server "C"? With asynchronous replication? With synchronous replication? After all, these are different devices and such inconsistency, even for a very short time, should theoretically be possible. Is consistency guaranteed in a system of multiple replicated servers?

Answer 1

guarantees ACID where the letter "C" stands for Consistency - Consistency.

Within the same postgresql cluster. Those. one server.
By design. That's why it's called an asynchronous replica. Between the commit on the master and the arrival of each individual asynchronous slave in this state, there will always be some kind of time lag.
But the timeline is one for all, because the master leads it. The situation that only X is written on B, and only Y is written on C is excluded.
Synchronous replica - the master will not respond to the client with "written" until it receives a response from synchronous replicas from synchronous_standby_names that they received these wal (default, ensures that the data is on at least two machines and you will not lose it in case of a sudden failure), applied these changes (synchronous_commit=remote_write, respectively, two postgresql clusters are synchronous. Due to the CAP theorem, it is theoretically possible that if the master fails, this transaction will already be written on the slave, and on the master it will be listed as interrupted. I don’t know what exactly has been done about this).
Note that if the synchronous replica goes down, the master will be read-only. All writing transactions will wait for the synchronous replica to return.
Depending on what you are allowed to sacrifice for this. See the CAP theorem.
This, of course, is only true for embedded WAL binary streaming replication. Logic in 10 will live by its own special rules, as well as third-party trigger solutions.

Answer 2

Question: is it possible that the keys "X" and "Y" are already replicated to the server "B", but not yet replicated to the server "C"? With asynchronous replication? With synchronous replication?

yes, probably, and at both types of replication. especially if the access speeds between the master and both slaves are significantly different.