Архитектура — это не про идеал. Это про стоимость изменений

На собеседованиях часто спрашивают: «Как бы вы спроектировали эту систему?». И ждут ответа с микросервисами, Kubernetes, Kafka и event-sourcing. Но в реальности самая сложная часть архитектуры — это не выбор технологий. Это выбор момента. Когда мы начинали текущий проект, у нас было три микросервиса. Сейчас — двенадцать. Не потому что так было задумано. А потому что монолит начал тормозить разработку, когда команда выросла с трёх человек до пятнадцати. Мы не рефакторили заранее. Мы рефакторили, когда стало больно. И это нормально. Архитектура — это не музей. Это живой организм. Её задача — минимизировать стоимость изменений. Если добавить новую фичу требует переписывания трёх модулей и согласования с четырьмя командами — архитектура проигрывает. Если вы меняете логику в одном месте, и это не ломает остальное — архитектура работает. Что я вынесла за пять лет в продакшене: Не усложняйте раньше времени. Монолит на старте — это преимущество. Быстрый деплой, простая отладка, единый контекст. Разбивайте только тогда, когда границы доменов станут очевидны, а не когда вы прочитали статью в блоге. Логируйте всё, что может сломаться. Не в консоль. В структурированный формат, с трейс-айди, метриками времени выполнения и кодами ошибок. Когда продакшен горит в три ночи, логи — это единственный фонарик. Договаривайтесь о контрактах заранее. API между сервисами — это не реализация. Это обещание. И если обещание меняется, все должны знать об этом до деплоя. Версионирование, schema registry, backward compatibility — это скучно. Но это то, что удерживает систему от коллапса. И главное: архитектура должна служить бизнесу, а не эго инженера. Красивое решение, которое никто не понимает и никто не может поддерживать — это технический долг в квадрате. Простота побеждает сложность. Но только та простота, которая выстрадана опытом.