Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture) Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от: - Политики и бюджета компании - Уровня команды (джуниоры vs эксперты) - Наследия систем и ограничений от объединения разных систем - Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет) Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения. По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований - Client → Database - Client → API → Database (добавили интерфейс) - Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности) - Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов - Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus - Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки - И так далее В общем, выступление очень интересное. Основные мысли примерно такие - Все компромиссы исходят из реальности, а не идеологии - Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда вы уже покинете компанию - Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете. Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься Мы не пишем код для компьютера, а для следующего разработчика, который, возможно, маньяк с топором. Не злите его #Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign