Which guarantees you actually need

In the next rack, just half a meter from Kotomarket's cache, stands its twin: the same kind of server with the same data. The station powers them up, and both light up at once.

The Commandant visibly relaxes: “So if there's a second one, the data is safe. We can read from either one?”

QUERY: You can read from either one. But sometimes they'll give different answers. You'll see in a moment.

Node and copy

A server that runs a data store is called a node. If all of the shop's working data lives on just one node, a server failure leaves the shop without access to that data. That is why working data is also kept on another node.

The second node receives changes from the first and tries to keep the same state. This constantly updated copy is also called a replica. It is like a second screen showing the same working data: something changes on the main node, and that change is sent onward.

It is easy to confuse a copy with a backup here. A backup snapshot is stored separately so you can later return to an earlier state after a mistake or data loss. The copy in this lesson lives alongside the running system and keeps receiving fresh changes. If a new city is written to the main node, the copy should receive that new city too, rather than deliberately keeping the old version.

In Redis, new data is written to the main node, which then sends the changes to the copy. Both nodes here are Redis: the shop's main database in PostgreSQL does not take part in this experiment.

The transfer is not instant. The main node first accepts the change itself, then sends it to the copy. While the message is still on the way, the main node already knows the new value, but the copy still remembers the previous one. This time difference is called copy lag.

Copies on other nodes are not unique to Redis. PostgreSQL and MongoDB, for example, have similar mechanisms. In real systems, engineers watch node state in server settings and monitoring panels: they check which node is the main one and whether the others are keeping up with changes.

In the cell below, the copy lags by exactly two seconds. The key city:42 stores the delivery city for customer 42. It does not need a time to live, and the city name is a single word, so double quotes are not needed either.

The customer first chooses «Новосибирск» (Novosibirsk). Five seconds later, they change their mind to «Казань» (Kazan). Right after that, we ask both nodes, giving us a chance to catch the moment when the new value has already been written in one place but is still traveling to the other.

A normal cli line talks to the main node. After the training console command, you can pass the marker node='copy' after a comma: then the command goes to the copy, and its replies appear after «копия>». In real work, you connect to the copy separately by running redis-cli with its address.

First, the main node replies «Казань» (Kazan). That is expected: this is where the new value was just written.

At the same moment, the copy replies «Новосибирск» (Novosibirsk). It has not lost Kazan or decided to argue with the main node. The change simply has not reached it yet, so the copy replies with the latest value it has already received.

Two seconds pass. Now the copy also replies «Казань» (Kazan). That means the lag is over: both nodes once again store the same value.

It is like two display boards with data passed between them after a short delay. The first already shows the new city, while the second still shows the old one for a few moments before updating.

On a cart page, you can live with this: the customer refreshes a little later, once the copy catches up with the main node, and sees the correct city. With an account balance, that kind of delay is much more unpleasant: an old value can affect a decision that cannot be safely repeated.

When the connection breaks

Lag by itself eventually ends: the change is on its way and sooner or later arrives. A much harder case is when the path between the nodes disappears completely.

Both servers can still remain online. The main node accepts new writes, and the copy continues answering requests, but they can no longer exchange fresh changes. In CAP, this situation is called a network partition.

Imagine two branches of a shop losing their connection to each other. Both are open and remember everything they knew before the break. But if a customer changes their city at one branch, the other will not know about it yet. The connection between parts of the system has failed, not the data inside each server.

cut_link() is a training function used in this course: real Redis does not have it. It simulates a network break. From this point on, the copy receives nothing new. And there is no way to know in advance when the connection will return.

A minute passes, and the copy still replies «Новосибирск» (Novosibirsk). It managed to receive that value before the break, while Kazan appeared only after the connection was lost. So waiting a few more seconds is pointless: until the path between the nodes is restored, the new value will not reach the copy.

If the page reads specifically from the copy, there are two options left.

• Answer with what is available. The page opens, but the customer sees the old city. The data store is available, even though the answer is currently wrong.
• Refuse to answer until the connection returns. The customer will not see the old city, but they will not see the page either.

The right choice depends on the task. For a cart or recommendations, an old answer is usually acceptable: it is better to show the page even if some information is slightly behind. During payment, it makes more sense to stop temporarily than to make a decision using an old balance.

There is another choice at write time. The system can reply as soon as the main node accepts the new value. The user gets confirmation faster, but at that moment the new value may exist only there.

Or the system can first wait until the copy accepts the change too, and only then consider the write complete. That gives more confidence: the new value is already stored in another place as well. The cost is clear — the write response takes longer.

This choice does not determine where the system later reads data from. You can wait longer for a write to finish and still read from the copy, or finish the write quickly and read from the main node. These are separate system decisions.

CAP matters specifically when communication between parts of the system is broken. While the nodes exchange data normally, this principle by itself does not force a choice between freshness and availability.

During a network partition, the nodes can no longer compare their new state with each other. Then you have to decide what matters more for a particular request: keep answering with available data, or refuse to answer when its freshness cannot be confirmed. We will return to CAP in chapter 7, when there are six nodes.

QUERY: The second server backs up the first. And it raises a new question: if they give different answers, which one should you trust?