Обратная сторона подхода база на сервис.
Допустим вам нужен какой то справочник(набор данных который везде одинаковый), и он нужен вам при старте, то есть вы не можете без него работать. Тогда если этот справочник закрыт апи, то вы не сможете стартовать сервисы если сервис справочник недоступен или его сломали при деплое. Тогда напрашивается вариант персистент с кешем в самих сервисах. Либо хранение этого справочника локально в каждом сеовисе. Что согласитесь довольно сильное усложнение всей архитектуры.
На мой взгляд нужно отталкиваться от требований и критичности сервисов. Если требования позволяют нужно упрощать, и нет ничего проще одной базы, к тому же как правило, база данных один из самых надежных компонентов системы, вероятность выхода из строя котрого гораздо ниже чем сервиса справочника.
Поэтому слепое следование практикам всегда плохо, всегда нужно взвешивать плюсы и минусы для вашего случая.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Допустим вам нужен какой то справочник(набор данных который везде одинаковый), и он нужен вам при старте, то есть вы не можете без него работать. Тогда если этот справочник закрыт апи, то вы не сможете стартовать сервисы если сервис справочник недоступен или его сломали при деплое. Тогда напрашивается вариант персистент с кешем в самих сервисах. Либо хранение этого справочника локально в каждом сеовисе. Что согласитесь довольно сильное усложнение всей архитектуры.
На мой взгляд нужно отталкиваться от требований и критичности сервисов. Если требования позволяют нужно упрощать, и нет ничего проще одной базы, к тому же как правило, база данных один из самых надежных компонентов системы, вероятность выхода из строя котрого гораздо ниже чем сервиса справочника.
Поэтому слепое следование практикам всегда плохо, всегда нужно взвешивать плюсы и минусы для вашего случая.