Микросервисы любят делать вид, что «всё уже описано». На практике — 10 сервисов, устаревшая схема в Confluence

Микросервисы любят делать вид, что «всё уже описано». На практике — 10 сервисов, устаревшая схема в Confluence и 2 дня на архитектурное решение. В таком хаосе обычная схема «нарисуем стрелочки» не работает: она прячет границы ответственности и ломает обсуждение на уровне деталей.

Что забрать в работу системному аналитику:

1) Сначала C4 на контекстном уровне: кто с кем общается, где внешние зависимости, где вход в систему.
2) Потом контейнеры: не «какие сервисы есть», а кто за что отвечает и где проходит граница ответственности.
3) Отдельно фиксируйте сценарии сбоев: что будет, если упадёт кэш, API‑шлюз или один из downstream-сервисов. Это часто важнее красивой диаграммы.
4) Храните архитектуру как код, а не как картинку в презентации — иначе через месяц она уже мертва.

Чёрный кейс здесь простой: без C4 команда спорит не про решение, а про терминологию. С C4 спор быстро превращается в проверяемые гипотезы: где ставим кэш, какой риск снимаем, что ломается при деградации. Это экономит не «время на созвон», а дни согласований ⚙️