Если это независимые базы без согласованного распределения данных, разные реплики users-api будут видеть разное состояние. Обычная балансировка запросов начнёт возвращать противоречивые результаты.
Сложности работы с БД в микросервисной среде
Если это независимые базы без согласованного распределения данных, разные реплики users-api будут видеть разное состояние. Обычная балансировка запросов начнёт возвращать противоречивые результаты.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
На схеме:
- webApp посылает запросы через GW и SD;
- сервис users-api развернут в нескольких экземплярах;
- каждый экземпляр users-api взаимодействует со своей отдельной базой данных (три независимых DB, вероятно, с репликацией).
Необходимо выявить и описать потенциальные проблемы такой схемы взаимодействия с базами данных в микросервисной архитектуре.
Ответ
Если это независимые базы без согласованного распределения данных, разные реплики users-api будут видеть разное состояние. Обычная балансировка запросов начнёт возвращать противоречивые результаты.
Сначала нужно определить модель: единая логическая БД с репликами, шардинг по стабильному ключу или намеренно распределённая запись. Асинхронная репликация даёт lag и read-after-write проблемы; multi-writer добавляет конфликты, а failover — риск split-brain. Для обычного users-api проще несколько stateless-реплик поверх одного управляемого кластера БД. При шардинге маршрутизация обязана знать shard пользователя. База «на каждый экземпляр сервиса» не является тем же, что database-per-service по бизнес-домену.