микросервисы - сущность характерная для более-менее активных нагрузок, ибо сама идея была на уровне горизонтального масштабирования.
То есть грубо если на 100500 запросов масштабировать монолит - то надо xN экземпляров монолита с такой же кратностью ресурсов, а если прикладная система рубится на те самые функциональные части (микросервисы), то оказывается что надо разное количество экземпляров для разных "кусков" (микросервисов), что на больших цифрах и даст профит.
Естественно у этого профита есть и обратная сторона - передача данных между микросервисами это совсем не то же самое что передача параметров в вызов метода (даже по значению) и т.п.
Так что для pet проектов - это всё будет баловством и натягиванием микросервисом за уши.
Но если уж очень захочется - можно и пострадать микросервисами головного мозга и сделать вычурное:
- взять и разделить всё например по api - грубо на каждую crud четвёрку - свой микросервис
- не дать взаимодействовать микросервисам между собой - пусть этим занимается отдельный микросервис-передаст
- аналогично базой - вот пусть с ней работает отдельный микросервис, а остальные ходят к нему (хотя это слегка нарушит концепт "каждому микросервису по своей БД")
Ну и дальше - каждый микросервис сможет пилить отдельная команда разработки -> каждому по своему репозиторию... ну а знание друг о друге микросервисов замкнутся на одном/нескольких репозиториях контрактов
Монстр - готов)