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

Когда в продукте десяток сервисов, устаревшая документация и на решение по архитектуре есть 2 дня, спор легко уходит в детали. В такой ситуации помогает C4-модель: она возвращает обсуждение на нужный уровень и фиксирует архитектуру без лишней воды.

Как применять на примере кэширования в API-шлюзе:

1. Сначала — контекст. Что именно меняется, где граница системы, какие внешние зависимости затронуты.
2. Затем — контейнеры и компоненты. Не «как вообще устроен сервис», а кто отвечает за кэш, где живёт логика, кто читает и пишет данные.
3. Дальше — сценарии сбоев. Что будет при промахе кэша, таймауте, рассинхронизации, недоступности downstream-сервиса.
4. В финале — зафиксировать решение как артефакт, который можно обновлять, а не хранить в голове у одного архитектора 📌

C4 полезна, когда нужно быстро синхронизировать команду и не утонуть в уровне кода. Не лучший выбор, если вы ищете не архитектурный обзор, а детальную спецификацию реализации.

Хороший ориентир для PM и аналитика: сначала покажите систему целиком, потом уже спорьте о частностях.