Есть ли опыт разработки с немонолитной архитектурой

Что проверяют

Работали ли вы в распределённой системе и понимаете ли её цену. Ответ «делали микросервисы» без деталей звучит слабо, потому что сложность там не в разделении, а в связности.

Как отвечать

Опишите систему: сколько сервисов, как они общались (HTTP, gRPC, очередь), как делились данные, была ли база одна на всех или у каждого своя. Последнее важно: несколько сервисов вокруг одной базы это распределённый монолит, а не микросервисы, и честно сказать об этом лучше, чем выдавать за архитектуру.

Дальше назовите то, с чем реально сталкивались:

• границы сервисов: по бизнес-возможностям, а не по слоям. Разрезали по данным или по командам;
• согласованность: транзакции больше нет, поэтому либо согласованность в конечном счёте с компенсациями, либо схема исходящих сообщений, чтобы запись в базу и отправка события не разъезжались;
• надёжность вызовов: таймауты, повторы с задержкой, идемпотентность, предохранитель на случай недоступности соседа;
• наблюдаемость: сквозной идентификатор запроса, распределённая трассировка, логи с общим форматом. Без этого разбор инцидента в распределённой системе невозможен;
• эксплуатация: отдельные выкаты, версии контрактов, обратная совместимость, миграции без простоя;
• тестирование: контрактные тесты между сервисами вместо сквозных прогонов всего.

Хорошо, если добавите взвешенную позицию: монолит с ясными модулями проще и дешевле, а разделение оправдано, когда команд много и их выкаты мешают друг другу, либо когда части системы нужно масштабировать по-разному.

Где спотыкаются

Называют микросервисами набор сервисов вокруг общей базы.

Не могут объяснить, что делают при отказе соседнего сервиса.

Считают разделение самоцелью и не называют цену: сеть, задержки, эксплуатация, отладка.