Акт III. Распределёнка · Одна база — одна точка отказа

Вот та самая деталь. Реплики повторяют изменения лидера не мгновенно: пока запись доедет по сети и применится, проходит время. Этот зазор называется отставанием реплик, и обычно он крошечный — миллисекунды. Но под нагрузкой, при сетевых заминках или сразу после failover он вырастает до секунд. А значит, реплика какое-то время отдаёт слегка устаревшие данные.

Отсюда — семейство коварных багов, которые не видно в спокойный день:

• Не вижу свою запись. Покупатель оформил заказ (запись ушла на лидер), тут же открыл «Мои заказы» (чтение прилетело на отставшую реплику) — и заказа нет. Он оформляет второй. Лекарство — чтение своих записей: свои свежие данные читаем с лидера, а не с реплики.
• Время идёт назад. Обновил страницу — заказ был, обновил ещё раз — пропал: два чтения попали на реплики с разным отставанием. Пользователь думает, что сходит с ума. Лекарство — monotonic reads: закрепить пользователя за одной репликой, чтобы время для него не шло вспять.

Всё это — лица одной сделки: мы разменяли идеальную согласованность на доступность и масштаб. Реплики почти всегда сходятся с лидером — это называют согласованностью в конечном счёте, — но «в конечном счёте» не значит «сейчас».

Так что репликация не бесплатна: она платит не деньгами, а маленькими окнами, в которых разные узлы рассказывают о мире чуть по-разному. Инженерная работа — не убрать эти окна (нельзя), а знать, где они недопустимы, и там читать с лидера.