Архитектура приложений
Тема дорожной карты · Backend разработчик
Бэкенд-архитектура — это совокупность структурных проектных решений, определяющих, как организованы серверные системы, как компоненты взаимодействуют и как система масштабируется для удовлетворения спроса. Наиболее распространённые архитектурные стили: монолитная архитектура (единая развёртываемая единица), микросервисная архитектура (небольшие независимые сервисы, взаимодействующие через REST, gRPC или брокеры сообщений Kafka и RabbitMQ), и модульный монолит (промежуточный вариант со строгими внутренними границами модулей). Выбор архитектуры предполагает взвешивание вариантов хранения данных: реляционные СУБД PostgreSQL и MySQL для транзакционных нагрузок, NoSQL-хранилища MongoDB или Cassandra для документальных или временны́х рядов, и Redis для кеширования и pub/sub — наряду со сквозными требованиями: аутентификация (JWT, OAuth 2.0), наблюдаемость (Prometheus, Grafana, OpenTelemetry) и стратегия развёртывания с Docker и Kubernetes. Продвинутые паттерны CQRS, DDD, event sourcing и Saga решают задачи согласованности и масштабируемости в распределённых системах. Хорошая бэкенд-архитектура документируется через ADR (Architecture Decision Records), диаграммы модели C4 и спецификации OpenAPI и проверяется CI/CD-пайплайнами, запускающими интеграционные и нагрузочные тесты перед каждым деплоем в продакшен.
Как это работает
Архитектура приложений имеет варианты: монолит (один деплоябл, простой ops, тяжело масштабировать команды за ~30 инженеров), modular monolith (один деплоябл, внутренние границы модулей, масштабируется намного дальше, чем считают), микросервисы (много мелких сервисов, сложный ops, масштабирует команды). Паттерны: hexagonal / clean architecture (отделить домен от инфры), CQRS (раздельные read + write модели), event sourcing (state из event log), domain-driven design (моделируем бизнес). "Правильная" архитектура — простейшая, решающая текущие ограничения.
Когда применять
Каждый новый проект — modular monolith. Разделяйте на сервисы только когда (а) в команде > ~30 инженеров, (б) у одного компонента сильно другие требования к масштабу, (в) регуляторные границы требуют изоляции. "Архитектура" — это в основном про что вы можете дёшево менять потом; принимайте решения, откладывающие необратимость (БД на сервис — очень необратимо; границы модулей в монолите — дёшево перерисовать).
Типичные ошибки
Ловушки Архитектура приложений: микросервисы для 5-инженерной команды (каждый сервис стоит ops + observability; больше дебажите RPC, чем шипите фичи); погоня за паттернами из FAANG-блогов на startup-масштабе (их ограничения не ваши); переписывание "ради clean architecture" без замеренной выгоды (clean ≠ better — только если окупается в изменяемости). Оптимизируйте под следующие 12 месяцев, не под 10x масштаб, которого нет.