Архитектура SaaS ломается не на масштабе, а на первых неудачных допущениях

Архитектура SaaS ломается не на масштабе, а на первых неудачных допущениях

Самая дорогая ошибка — строить систему вокруг абстракций, а не вокруг сценариев продукта. Сначала фиксируйте 3 вещи: кто пользуется, какие операции самые частые, где ошибка стоит дороже всего. От этого зависит, нужен ли монолит, модульный монолит или уже разнос по сервисам.

Дальше проверьте границы доменов: биллинг не должен знать детали профиля, уведомления — логику платежей, а аналитика — жить внутри транзакционного пути. Если модуль тянет за собой соседний блок при любом изменении, граница проведена плохо. 1

Отдельно закладывайте слабые места: очереди для фоновых задач, идемпотентность для повторных запросов, единый слой логирования и понятные таймауты. Архитектура считается удачной не тогда, когда всё красиво на схеме, а когда сбой одного узла не валит весь продукт.

Перед рефакторингом задайте себе один вопрос: эта сложность уже продаёт ценность или только выглядит взрослой? Если ответа нет, оставляйте систему проще и стройте точки роста вокруг реальных узких мест.