Как обеспечить приемлемую консистентность при чтении с read-реплик с задержкой репликации (replication lag)? Обсудите компромиссы, риски и критерии выбора — единственного правильного решения может не быть?

Короткий ответ

Чтение с асинхронных read-реплик снижает нагрузку на primary, но может возвращать отстающие данные, особенно заметные сразу после записи самим же пользователем; решение о том, где можно читать с реплики, а где нужен primary, принимается отдельно для разных сценариев использования.

Как это работает подробнее

Запись идёт на primary; реплики применяют изменения асинхронно с задержкой; чтение с реплики сразу после записи тем же пользователем может не увидеть эту запись, если реплика ещё не успела её применить.

Полный перевод критичных по свежести чтений на primary гарантирует согласованность, но нагружает единственный узел записи; чтение с реплик для всего трафика максимизирует масштабируемость, но создаёт видимые артефакты задержки там, где это критично. Промежуточный вариант (sticky-роутинг на primary после записи) даёт баланс, но требует дополнительной логики роутинга и усложняет инфраструктуру чтения.

Пример кода

СхемаКопировать

Сценарий: пользователь обновил имя профиля, затем немедленно переходит на страницу профиля.
Без read-your-writes: запрос попадает на реплику с lag 300ms -> видит старое имя.
С read-your-writes: запрос в течение N секунд после записи явно идёт на primary -> видит новое имя.

Что использовать на практике

• Практика. Для сценариев read-your-writes применяют чтение с primary сразу после записи в рамках той же сессии, либо передачу «позиции» записи клиенту для ожидания догона репликой; для чтения чужих давних данных небольшой lag почти не критичен.

Подводные камни

• Риск. Читать со случайной реплики без учёта контекста операции сразу после собственной записи пользователя; переводить всё чтение на primary «для надёжности», убивая смысл масштабирования через реплики.