Когда использовать микросервисы, а когда database join?

Question

[Николай Кочнев]

В процессе разработки одного из сервисов у меня с коллегой возник архитектурный конфликт, нужен взгляд со стороны.

Основная функция разрабатываемого сервиса - отправка данных из нашей системы во внешнюю. В процессе подготовки данных необходимо наши идентификаторы адресов преобразовать в ФИАС. Для этого у нас есть еще один микросервис, который держит базу данных ФИАС в актуальности и линует с нашей адресной системой.
Связать данные двух сервисов можно двумя путями:
1. через http: фиас сервис предоставляет api для получения данных, сервис отправки дергает нужные методы и собирает данные в приложении
2. через простой join нужных таблиц в хранимой процедуре подъема данных сервиса отправки, данные собираются в БД

Первый подход:
- разделение ответственности сервисов
- независимое хранение данных: при переносе БД с одного сервера на другой, не нужно вносить изменения в сервисы-клиенты
- больше контроля над приложением, возможность тестирования

Второй подход:
- более высокая производительность

Вопрос: какой подход выбрать? Какие есть плюсы/ минусы обоих подходов, которые мы не учли?

Answer 1

[Александр Ананьев]

Очевидно, первый. Второй вызовет много проблем при изменении структуры базы данных

Answer 2

[Максим Кузнецов]

Первый подход требует постоянной доступности внешнего стороннего сервиса. Без этого работать не будет совсем. Я бы делал кэш нужных данных в своей системе, обновляемый с заданной периодичностью клиентом, подключающимся к сервису на стороне ФИАС (лезть в БД, особенно чужую, напрямую не комильфо). Плюс такого кэша в том, что ваша система будет работать независимо от того, доступен ли источник данных на стороне ФИАС, или нет. Ещё один плюс - слой абстракции от внутренней инфраструктуры ФИАС: сервис будет меняться гораздо реже структуры БД. Дополнительно можно контролировать версии передаваемых данных.

А дальше - полёт фантазии. Кроме указанных вариантов можно рассмотреть ещё несколько решений. Например, по расписанию в БД заполнять некоторую таблицу-"витрину" нужного формата, из которой уже напрямую отдавать данные куда угодно. Такое решение удобно, если построение "витрины" происходит долго из-за объёмов данных. Заранее готовите данные и потом моментально отдаёте.