Когда у проекта десяток микросервисов, устаревшая документация и на согласование архитектуры всего два дня, сп

Когда у проекта десяток микросервисов, устаревшая документация и на согласование архитектуры всего два дня, спор обычно уходит в детали: какой кеш, где ставить, кто владеет риском. C4-модель здесь полезна не как «красивая схема», а как инструмент управления решением.

Что делать системному аналитику:

1. Сначала — контекст.
Покажите границы системы: где API-шлюз, какие сервисы с ним взаимодействуют, где внешние зависимости. Это сразу снимает половину лишних вопросов.

2. Потом — контейнеры и зоны ответственности.
Для кейса с кешированием важно не только «что меняем», но и кто отвечает за TTL, инвалидацию, fallback и поведение при сбое. Именно здесь всплывают риски для SLA и денег.

3. Затем — сценарии отказа.
Если кеш недоступен, шлюз падает в origin или деградирует? Если данные устарели, кто и как это увидит? Такие вещи лучше фиксировать до релиза, а не после инцидента.

Хорошая практика — хранить C4-схемы как код в репозитории. Тогда архитектура живёт вместе с продуктом, а не лежит мёртвым PDF. Это экономит время команды и снижает цену ошибочного решения. 📌