Немножко большая функция ахах

/start

Вопрос к любителям и профессионалам микросервисов:

1 микросервис - 1 бд
Есть микросервис, отвечающий за регистрацию, аутентификацию. У него есть бд с айдишниками, никнеймами и паролями.

Допустим есть еще другой микросервис, который должен отправлять нотификации пользователям. У этого микросервиса в его личной бд есть список email'ов, телефонов и т.п., на которые надо отправить оповещения.

Но в этой же таблице также должны быть и айдишники пользователей... т.к надо связывать строку с почтой/телефоном и т.п. с пользователем.

Но разве тут не будет нарушения: одна бд - один микросервис?

Как решается такое? Как добиться изолированности (гранулярности) данных?

Ээ, а нафиг тебе отдельную базу данных на каждый микросервис?

Так это типа закон, на сколько я понял.

Как вариант решения, видел, что все взаимодействие с бд выносят в отдельный микросервис. Но тогда по сути не вижу отличия этого микросервиса от монолита.

Обычно одна база на всё

У каждого сервиса могут быть свои небольшие локальные базы, например для кэшей

И это ни в коем разе не превращает систему в монолит

+

Никогда не слышал о таком

Ну как же так???
В том то и прикол микросервисной архитектуры, что её легко расширять горизонтально.
И суть отдельной собственной бд в том, что миграции и изменение данных в одном микросервисе (его бд) никак не влияли на данные в другом.

БД это не сервис

Изолированность данных это ж по сути и есть одна из фишек микросервиса

Выносить всю работу с БД в отдельный сервис нерационально. Это сильно замедлит работу и усложнит взаимодействие между компонентами

Ты не понимаешь

БД это бд

Сервис это сервис

Суть микросервисах не в разделении данных, а в разделении обработчиков этих данных

Обе эти фишки - суть микросервисной архитектуры.

Но разделение процессов обработки и в монолите происходит: один запрос - один процесс. (Правда хз, что там с asyncio)