Какие плюсы у монолитной архитектуры
Что проверяют
Понимаете ли вы, как архитектура влияет на тестирование: сколько окружений поднимать, где искать баг, что гонять в регрессе. Следом почти всегда спрашивают про минусы монолита и чем тестирование микросервисов отличается от тестирования одного приложения.
Как отвечать
Монолит это одно приложение с общей кодовой базой, одним артефактом сборки и чаще всего одной базой данных. Плюсы стоит называть с точки зрения QA:
- одно тестовое окружение: чтобы проверить фичу целиком, достаточно поднять приложение и базу, не нужно собирать десяток сервисов совместимых версий;
- простые E2E и интеграционные сценарии: вызовы между модулями идут внутри процесса, нет сетевых таймаутов, ретраев и частичных отказов, которые порождают нестабильные тесты;
- транзакционная целостность: заказ и списание остатка пишутся в одной транзакции, поэтому не нужно отдельно проверять согласованность данных между сервисами и компенсирующие сценарии;
- один релиз, одна версия: всегда понятно, какая сборка стоит на стенде, нет матрицы совместимости и контрактных тестов между командами;
- локализация бага: один лог, один стек вызовов, отладчик проходит запрос насквозь;
- низкий порог входа: новому тестировщику проще разобраться в системе и развернуть её локально.
Хорошо добавить, когда монолит оправдан: небольшая команда, ранняя стадия продукта, домен ещё меняется. Многие начинают с модульного монолита, где модули разделены чёткими границами, но деплоятся вместе.
Где спотыкаются
Перечисляют плюсы как абстрактные «проще и быстрее» без связи с тестированием. Для QA вопрос именно про то, как архитектура меняет стратегию проверок.
Забывают обратную сторону тех же плюсов: любое изменение попадает в общий артефакт и требует широкого регресса, а долгий релизный цикл копит правки в большие рискованные выкатки.
Считают монолит устаревшим подходом. Для многих продуктов он дешевле в разработке и поддержке, а переход на микросервисы без явной причины добавляет сложности, в том числе в тестировании.