Для чего нужны реплики
Что проверяют
Понимаете ли вы, что реплика даёт и чего не даёт, и как это отражается в коде сервиса. Следом обычно спрашивают про отставание: пользователь сохранил профиль, обновил страницу и увидел старые данные, что делать.
Как отвечать
Сначала уточните, о каких репликах речь: о копиях базы или об экземплярах сервиса в Kubernetes (replicas в Deployment). Чаще имеют в виду базу, по ней и отвечайте.
- отказоустойчивость: при падении основного узла реплику повышают до мастера. В PostgreSQL это обычно автоматизирует Patroni, в управляемых облачных базах сам провайдер;
- масштабирование чтения: тяжёлые SELECT, отчёты и аналитику отправляют на реплики, мастер остаётся для записи;
- география и изоляция: реплика ближе к пользователям или отдельная реплика под выгрузки, чтобы они не мешали основной нагрузке.
Режимы. Асинхронная репликация быстрая, но у реплики есть лаг, и при аварии мастера можно потерять последние подтверждённые транзакции. Синхронная (synchronous_commit и synchronous_standby_names в PostgreSQL) данные не теряет, зато каждая запись ждёт реплику, и её недоступность тормозит мастер.
В Go разделение чтения и записи делается явно: ни database/sql, ни pgxpool сами не разводят запросы по узлам. Обычно держат два пула, для мастера и для реплик, и выбирают нужный в слое репозитория, либо берут библиотеку выбора узла кластера вроде hasql. Правило простое: чтение сразу после записи и всё внутри транзакции идёт на мастер.
Где спотыкаются
Называют реплику бэкапом. Ошибочный DELETE или DROP TABLE уедет на реплику за доли секунды, от этого защищают бэкапы с point-in-time recovery.
Думают, что реплики масштабируют запись. Все записи по-прежнему идут через один мастер, для роста записи нужны шардирование или другая архитектура.
Забывают про лаг и читают с реплики то, что только что записали в мастер. Отсюда «исчезающие» заказы и повторные отправки форм, которые трудно воспроизвести на тестовом стенде без нагрузки.