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

Смотри, идея до смешного простая: держи не одну копию данных, а несколько, на разных узлах. Это и есть репликация. Одна копия — это не система, а отложенная авария; несколько — уже страховка.

Самая распространённая схема — лидер и реплики. Один узел объявляется лидером: только он принимает записи. Все изменения он потоком пересылает репликам-follower'ам. Реплики повторяют их у себя и готовы в любой момент подхватить работу. Заодно они разгружают чтение — ровно это «Ярмарка» уже делала с аналитикой (реплика для чтения появилась ещё раньше).

Ключевой вопрос — когда лидер считает запись состоявшейся. Здесь развилка:

• Синхронно: лидер отвечает «готово» только после того, как запись подтвердила реплика. Ничего не потеряется, даже если лидер тут же сгорит, — но лидер вынужден ждать.
• Асинхронно: лидер отвечает сразу, а репликам шлёт изменения следом. Быстро — но если лидер упадёт раньше, чем догонит реплика, последние записи (в том числе только что оформленные заказы) исчезнут.

И то, ради чего всё затевалось, — переключение. Лидер упал → одна из реплик становится новым лидером, трафик записи идёт к ней. Сделай это автоматически и за секунды — и вчерашние одиннадцать минут превратятся в паузу, которую половина пользователей даже не заметит.

Звучит как решение всех бед. Но у копий есть одно коварное свойство, из-за которого дьявол прячется в деталях: они не всегда совпадают с оригиналом. К этому — через шаг.