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