Монолитная и микросервисная архитектура: что выбрать для своего диджитал-продукта
Перед началом разработки нового продукта важно определиться с его архитектурой. От вашего решения зависит, во сколько обойдётся разработка продукта, насколько легко будет добавлять в него новые функции и сможет ли он работать бесперебойно при больших нагрузках. Объясняем нюансы двух архитектур на схемах и примерах.
Главное чтобы ваше микросервисное приложение не превратилось в «распределенный монолит» (грубо говоря когда число связей начинает экспоненциально расти от числа компонентов).
Это фатальная точка, дальше только все выбрасывать - починить это будет стоить дороже, чем написать с нуля).
Еще один момент - нет смысла делать сильно филигранную нарезку на микросервисы, если у вас условно одна команда.
Одна команда — это необязательно два разработчика (бэкенд и фронтенд). Если в команде много разработчиков, то микросервисная архитектура во многом помогает избежать конфликтов в коде при разработке, потому что разные разработчики могут работать над разными микросервисами. При монолитном подходе этого избежать сложнее.
А ещё при микросервисной архитектуре можно обновлять только часть приложения. И это сделать сильно проще, чем при монолитной.