Ключевые выводы

Архитектура — компромисс, а не медаль. Нет «лучшего» стека на все случаи. Есть набор trade-off'ов: скорость разработки vs масштабируемость, простота деплоя vs независимость команд, богатый UX vs SEO и первая загрузка.

Технологии цикличны. Серверный рендеринг → AJAX → SPA → SSR снова. Монолит → микросервисы → modular monolith. Каждый виток спирали сохраняет уроки предыдущего поколения.

Копировать Big Tech опасно без их контекста. Netflix разрезал монолит, когда у него были сотни инженеров и собственная платформа облака. Стартап с тремя разработчиками получит распределённый монолит — все минусы сложности без выигрыша в масштабировании.

Наблюдаемость и данные — часть архитектуры с 2010-х. Логов в stdout недостаточно для систем из двадцати сервисов. Метрики, трейсы и полиглотное хранение — не «инфраструктурная роскошь», а условие сопровождаемости.

ИИ в 2020-х добавляет новый слой. Векторные базы, RAG, оркестрация вызовов LLM — это не «ещё один API», а отдельная архитектурная ось рядом с классическим backend.

---

Введение: почему архитектура никогда не стоит на месте

Веб-приложение — это всегда соглашение между тремя силами: что хочет пользователь (быстро, удобно, надёжно), что может железо и сеть (латентность, пропускная способность, батарея телефона) и что может команда (число людей, опыт, бюджет на инфраструктуру). Когда любая из этих сил сдвигается, пересматривают архитектуру.

Рост аудитории давит на горизонтальное масштабирование и кэширование. Ускорение интернета и появление 4G/5G позволили переносить логику в браузер — отсюда SPA и тяжёлые фронтенды. Мощные смартфоны сделали возможным JavaScript, который раньше «тормозил» на каждом клике. Облака снизили цену экспериментов с распределёнными системами — и одновременно подняли цену ошибок в эксплуатации.

Важно отделить устаревшее от ошибочного. CGI-скрипты на Perl в 2003 году были разумным выбором: простой деплой, понятная модель, минимум зависимостей. То, что сегодня для нового проекта вы бы выбрали FastAPI или Rails, не делает Perl «плохим» — он решал задачи своей эпохи в рамках тогдашних ограничений.

---

Глава 1. Веб начала 2000-х: эпоха серверного рендеринга

Как выглядел типичный сайт в 2005 году

Типичный сценарий был линейным: браузер отправляет HTTP-запрос → веб-сервер (Apache, IIS, nginx в зачаточном виде) передаёт его приложению → приложение читает данные из MySQL или PostgreSQL → шаблонизатор собирает HTML → сервер отдаёт готовую страницу. JavaScript на странице, если и был, ограничивался валидацией форм, простыми эффектами и счётчиками. Любое действие — смена фильтра, добавление в корзину, отправка комментария — чаще всего означало полную перезагрузку документа.

Для пользователя это означало заметные паузы и «мигание» белого экрана. Для разработчика — предсказуемость: вся логика на сервере, состояние в сессии или cookie, отладка через логи на одной машине.

Популярные технологии

Общая черта: язык на сервере генерирует HTML. Клиент — тонкий терминал для отображения.

Типичная архитектура

[Браузер] → [Веб-сервер] → [Монолитное приложение] → [Шаблонизатор] → HTML
                                    ↓
                              [База данных]

Три слоя, один процесс (или кластер идентичных процессов за балансировщиком). Деплой — залить файлы по FTP или перезапустить один WAR-файл. Никаких отдельных «фронтенд-сборок», API-контрактов между командами, оркестраторов контейнеров.

Плюсы и минусы

Плюсы: низкий порог входа; один репозиторий и один деплой; SEO «из коробки» — поисковик видит готовый HTML; относительно простая отладка и мониторинг.

Минусы: каждый клик — round-trip на сервер; сложно строить богатый интерактивный UI; сервер тратит CPU на рендеринг страниц при каждом запросе; горизонтальное масштабирование упирается в сессии и общую БД.

Эта модель не исчезла. Она эволюционировала — во фреймворки с MVC, в SSR фреймворки нового поколения, в HTMX-подход «HTML с сервера, минимум JS». Но в 2005 году она была единственным массовым ответом на вопрос «как сделать сайт с данными».

---

Глава 2. Появление AJAX и рождение Web 2.0

Что изменилось

В середине 2000-х страницы перестали полностью перезагружаться при каждом действии. Браузер начал запрашивать только данные — JSON, XML или кусок HTML — и обновлять часть DOM. Пользователь получил ощущение «приложения внутри браузера» без установки клиента.

Революция AJAX

AJAX (Asynchronous JavaScript and XML) опирался на XMLHttpRequest — API, появившееся ещё в Internet Explorer 5, но ставшее массовым после стандартизации и примеров от Google. Асинхронный запрос не блокировал UI; ответ обрабатывался callback'ом и менял интерфейс локально.

Ключевой сдвиг: сервер отдаёт данные, клиент решает, как их показать. Граница ответственности сместилась.

Проекты, изменившие индустрию

• Gmail (2004) — почта без перезагрузки вкладки; доказал, что веб может конкурировать с десктопом.
• Google Maps (2005) — панорамирование и зум без round-trip; показал ценность плавного UI.
• Facebook — лента, лайки, уведомления в реальном времени; масштабировал паттерн на сотни миллионов пользователей.

Эти продукты не «изобрели JavaScript» — они показали бизнес-ценность богатого клиента. Конкуренты вынуждены были копировать UX.

Новые проблемы и последствия

Логика разделилась между сервером и браузером без чётких контрактов. Дублирование валидации: на клиенте «для удобства», на сервере «для безопасности». JavaScript на страницах вырос с килобайт до мегабайт. Появились первые «спагетти» из callback hell.

Последствие для архитектуры: начался многолетний перенос состояния и поведения в клиент. Через десять лет это приведёт к SPA; в 2007 году — к первым REST-подобным эндпоинтам «для фронта».

---

Глава 3. Эпоха MVC-фреймворков

Почему появились MVC-фреймворки

С ростом AJAX-приложений и числа страниц монолитные скрипты «всё в одном файле» перестали масштабироваться организационно. Нужны были соглашения: где живёт бизнес-логика, где представление, где обработка запросов. MVC (Model–View–Controller) дал общий словарь.

Популярные решения

• Ruby on Rails (2004) — «convention over configuration», Active Record, генераторы; ускорил стартапы.
• Symfony, CodeIgniter, Yii, Laravel — экосистема PHP с зрелыми ORM и экосистемой пакетов.
• ASP.NET MVC — ответ Microsoft на Rails для .NET-мира.
• Django, Spring MVC — Python и Java с тем же разделением.

Концепция MVC

• Model — данные и бизнес-правила (часто через ORM).
• View — шаблон того, что увидит пользователь.
• Controller — принимает HTTP-запрос, вызывает модель, выбирает view.

Запрос проходит предсказуемый путь; новый разработчик в проекте понимает структуру за день, а не за месяц.

Что дала MVC-архитектура

Более чистый код, переиспользование partial-шаблонов и layout'ов, ускорение разработки CRUD-приложений. Появились соглашения деплоя: миграции БД, окружения, asset pipeline.

Ограничения

Толстые контроллеры — вся логика осела в слое, который должен был только маршрутизировать. Толстые модели — Active Record смешивает персистентность и домен. Монолиты росли: один репозиторий, десятки модулей, общая база. MVC организовала код внутри монолита, но не решила проблему масштабирования команд — отсюда путь к сервисам и микросервисам.

---

Глава 4. JavaScript становится полноценным языком фронтенда

Рост возможностей браузеров

Движок V8 (Chrome, 2008) и соревнование браузеров за скорость JIT-компиляции сделали JavaScript пригодным для тысяч строк логики, а не только для скриптов на 50 строк. Появились ES5, модули, Canvas, Web Workers. JavaScript перестал быть «языком для кнопочек».

Первые фронтенд-фреймворки

jQuery не убивал серверный рендеринг — он оживлял страницы поверх него. Backbone и Ember уже предполагали, что клиент владеет состоянием.

Проблема: интерфейс сложнее сервера

На сложных экранах (дашборды, редакторы, многошаговые формы) код представления обгонял серверный по объёму и сложности. Команды нанимали «фронтенд-разработчиков» как отдельную роль. Сборка (Browserify, позже Webpack) стала обязательной.

Появление SPA

Single Page Application — одна HTML-оболочка, дальше навигация и данные через JavaScript и API. URL меняется через History API; контент подгружается без полной перезагрузки. UX приближается к нативным приложениям; цена — тяжёлый первый загрузочный бандл и сложность SEO без дополнительных ухищрений.

---

Глава 5. Революция Angular, React и Vue

Почему SPA захватили рынок

После смартфонов и App Store пользователи ожидали мгновенной реакции интерфейса. SPA давали плавные переходы, оптимистичные обновления, офлайн-кэш (Service Workers позже). Для B2B-дашбордов и SaaS это стало стандартом качества.

Три столпа

Angular (2010, перезапуск 2016) — полный фреймворк: маршрутизация, DI, формы, HTTP-клиент. TypeScript по умолчанию. Подход «всё включено» удобен энтерпрайзу с долгими циклами планирования.

React (2013) — библиотека UI с компонентной моделью и Virtual DOM. Не диктует маршрутизацию и состояние — экосистема (Redux, React Router) выбирается отдельно. Переиспользуемые компоненты изменили дизайн-системы.

Vue (2014) — низкий порог входа, реактивность «из коробки», постепенное внедрение в legacy-страницы. Быстро вырос в Китае и Европе.

Как изменилась архитектура

Backend стал API. Сервер реже отдаёт HTML — чаще JSON по REST. Frontend стал отдельным приложением со своим репозиторием, CI, деплоем на CDN или статический хостинг. Контракт между командами — OpenAPI-документ (позже) или устная договорённость (часто и болезненно).

Появился типичный стек 2015–2020: React + Node.js (BFF или полноценный API) + PostgreSQL + Redis + Docker. Разделение позволило нанимать специалистов; усложнило версионирование API и согласование релизов.

---

Глава 6. Рождение API-first архитектуры

Что такое API-first

Сначала контракт, потом реализация. Команды описывают эндпоинты, схемы запросов и ответов, коды ошибок — до написания кода. Клиенты (веб, iOS, Android, партнёры) могут работать параллельно с backend по mock-серверам.

REST как стандарт

REST (Representational State Transfer) закрепил привычные паттерны:

• Ресурсы — /users/42, /orders/99/items
• HTTP-методы — GET читает, POST создаёт, PUT/PATCH обновляет, DELETE удаляет
• JSON — лёгкий формат для JavaScript-клиентов

Простота объяснения и отладки через curl сделала REST доминирующим стилем публичных API.

Плюсы

Независимость команд и клиентов; один backend для веба и мобильных приложений; проще интеграции с партнёрами и webhook'ами.

Минусы

Версионирование — /v1/ vs заголовки vs ломающие изменения в том же URL. Избыточные запросы — экран профиля тянет пять GET для связанных сущностей (проблема, которую позже атаковал GraphQL). Overfetching — клиент получает поля, которые не показывает.

API-first остаётся здравым принципом; спор идёт о форме API (REST, GraphQL, gRPC, tRPC для full-stack TypeScript).

---

Глава 7. Появление микросервисов

Почему ушли от монолитов

Когда в монолите работают пятьдесят команд, каждый деплой — лотерея: чужой модуль ломает ваш. Общая база данных становится узким местом и полем конфликтов миграций. Горизонтальное масштабирование «всего приложения» дороже, чем масштабирование только сервиса отчётов или поиска.

Что такое микросервис

Небольшой самостоятельный сервис с собственной базой данных (в идеале), своим деплоем и чёткой зоной ответственности. Общается по сети — HTTP, gRPC, очереди сообщений.

Кто популяризировал

Публичные истории Netflix, Amazon («two-pizza teams»), Google (внутренняя инфраструктура на годы раньше рынка) создали нарратив: успех гигантов связан с микросервисами. Менее публично обсуждали стоимость — сотни инженеров платформы, культура blameless postmortem, зрелый мониторинг.

Типичная архитектура

[Клиенты] → [API Gateway] → [Сервис A] [Сервис B] [Сервис C]
                ↓                    ↓         ↓
           [Auth]              [БД A]   [Очередь] → [Сервис D]

Gateway — единая точка входа, TLS, rate limiting, маршрутизация. Очереди (RabbitMQ, Kafka) — асинхронные задачи и слабая связность.

Преимущества и недостатки

Плюсы: независимый деплой; масштабирование отдельных сервисов; технологическое разнообразие (Python для ML, Go для воркеров).

Минусы: распределённые транзакции и согласованность; сетевые сбои и каскадные отказы; сложность локальной разработки («подними 15 контейнеров»); нужна наблюдаемость уровня, которого монолит не требовал.

Микросервисы — инструмент организационного масштаба, а не технический апгрейд по умолчанию. Подробнее о ловушках роста сложности — в статье почему ERP превращаются в монолитов.

---

Глава 8. Контейнеризация и Docker

Почему Docker изменил рынок

До Docker разработчик говорил: «У меня работает» — и падал на проде из-за другой версии libc, отсутствующего расширения PHP или несовпадения путей. Виртуальные машины решали изоляцию, но были тяжёлыми: минуты на старт, гигабайты на диск.

Что принес Docker

Контейнер — изолированный процесс с собственной файловой системой из образа. Образ собирается из Dockerfile, версионируется в реестре (Docker Hub, ECR, GCR). Одинаковый артефакт от laptop до production.

Влияние на архитектуру

Деплой ускорился: docker pull + перезапуск вместо ручной настройки сервера. Микросервисы стали практичными — не «15 JVM на 15 VM», а «15 лёгких контейнеров на нескольких хостах». Появился слой оркестрации — без него десятки контейнеров на ручном управлении нежизнеспособны.

---

Глава 9. Kubernetes и облачная революция

Почему Docker недостаточно

При сотнях сервисов нужны: автоматический restart упавших контейнеров, балансировка трафика, rolling update без даунтайма, secrets, лимиты CPU/RAM, service discovery — чтобы payments-v2 находил users без hardcoded IP.

Что принёс Kubernetes

Декларативные манифесты: желаемое состояние (3 реплики, образ app:1.2.3), кластер сам подтягивает фактическое. HPA — автомасштабирование по CPU или кастомным метрикам. Self-healing — пересоздание pod'ов на упавших нодах.

Новая реальность

Infrastructure as Code — Terraform, Pulumi; GitOps — Argo CD, Flux; термин Cloud Native — приложения, спроектированные под динамическую среду, а не под «вечный сервер».

Цена успеха

Резкий рост операционной сложности. Команда из восьми разработчиков редко нуждается в полном K8s-кластере; managed-платформы (ECS, Cloud Run, Fly.io, Railway) сознательно продают «меньше Kubernetes в лицо».

---

Глава 10. Serverless-подход

Идея

Не управлять серверами вообще — загружаешь функцию, платформа запускает её по событию (HTTP, очередь, cron). Масштабирование до нуля и до тысяч инстансов — задача облака.

Платформы

AWS Lambda, Azure Functions, Google Cloud Functions; надстройки вроде Vercel Functions и Cloudflare Workers ближе к edge.

Когда полезен

Нестабильная нагрузка (раз в час один запрос vs пик в Чёрную пятницу); событийные пайплайны (файл загружен → обработка → уведомление); быстрые прототипы API.

Ограничения

Cold start — пауза при первом вызове после простоя; критично для latency-sensitive API. Лимиты времени выполнения и размера пакета. Vendor lock-in — привязка к API и экосистеме одного облака. Отладка и локальная эмуляция сложнее, чем у контейнера.

Serverless — не замена всему backend, а специализированный слой для коротких stateless задач.

---

Глава 11. Возвращение серверного рендеринга

Почему SPA критикуют

Типичный React-SPA на первом визите: пустой HTML → скачать JS (сотни KB–MB) → выполнить → запросить данные → отрисовать. Медленная первая загрузка бьёт по LCP и конверсии на мобильных сетях. SEO без SSR/пререндера проблематичен для контентных сайтов. Доступность и работа без JS страдают, если весь контент клиентский.

Новое поколение фреймворков

• Next.js — SSR, SSG, ISR на React; де-факто стандарт для full-stack React.
• Nuxt — то же для Vue.
• Remix — веб-стандарты, вложенные маршруты, прогрессивное улучшение.
• SvelteKit, Astro — меньше JS на клиенте, островная архитектура.

Подходы

Гибридная архитектура

Статические страницы — SSG; личный кабинет — клиентская интерактивность; каталог — SSR с кэшем CDN. Лучшее из двух миров — если команда готова к сложности сборки и двух сред выполнения (сервер + браузер).

---

Глава 12. Современные архитектурные стили

Modular Monolith

Монолит с жёсткими границами модулей внутри одного деплоя. Модули общаются через явные API, не лезут в чужие таблицы. Проще сопровождать, чем распределённая система; дешевле, чем микросервисы для команды до ~20 человек. Модуль можно позже вырезать в сервис, если границы уже доказаны.

Снова популярен после волны «разрезали монолит и пожалели».

Микросервисы — когда оправданы

Очень большие продукты, десятки автономных команд, разные профили нагрузки подсистем, зрелая платформа (K8s, observability, SRE). Без этого — распределённый монолит с сетевой латентностью.

Event-Driven Architecture (EDA)

Сервисы публикуют события («Заказ создан»), подписчики реагируют асинхронно. Слабая связность, масштабирование потребителей, аудит через лог событий.

Инструменты: Apache Kafka (высокая пропускная способность, хранение), RabbitMQ (классические очереди), NATS (лёгкий, cloud-native).

CQRS

Command Query Responsibility Segregation — разные модели для записи и чтения. Запись идёт в нормализованную OLTP-базу; чтение — из денормализованных проекций или отдельного хранилища. Применяют при экстремальной нагрузке на чтение и сложных отчётах; цена — сложность синхронизации и задержка eventual consistency.

---

Глава 13. Архитектура фронтенда сегодня

Component-Based Architecture

React, Vue, Angular по-прежнему строят UI из переиспользуемых компонентов с изолированным состоянием и пропсами. Отличия — в экосистеме, модели реактивности и корпоративных требованиях.

Design Systems

Единые библиотеки (Material, Ant Design, собственные Storybook-киты) синхронизируют визуал и поведение между продуктами. Архитектурный выигрыш — меньше дублирования, быстрее согласование с дизайном.

Micro Frontends

Независимые команды деплоят части одного портала (шапка — команда A, каталог — B). Module Federation, iframe, web components. Оправдано при организационном разделении; дорого в интеграции и производительности на старте.

BFF (Backend for Frontend)

Специализированный API под конкретный клиент: мобильному BFF отдаёт агрегированный экран одним запросом; веб-BFF — другую форму. Снижает overfetching и скрывает внутреннюю микросервисную кашу от тонкого клиента.

---

Глава 14. Как менялись базы данных

Эра SQL

MySQL, PostgreSQL, Oracle — ACID, JOIN'ы, строгая схема. Десятилетиями один источник правды для монолита. PostgreSQL в 2010–2020-х съел значительную долю «универсальной» БД за счёт JSON, расширений и надёжности.

NoSQL-революция

Рост нагрузок Web 2.0 и нежелание жить в жёсткой схеме при быстро меняющемся продукте:

• MongoDB — документы, гибкая схема
• Cassandra — запись в ширину, отказоустойчивость
• Redis — кэш, сессии, очереди, структуры данных в памяти

CAP-теорема и eventual consistency вошли в обязательный словарь архитектора.

NewSQL и полиглотная персистентность

CockroachDB, TiDB — распределённый SQL с горизонтальным масштабированием. Polyglot Persistence — разные хранилища под задачи: PostgreSQL для транзакций, Elasticsearch для поиска, Redis для кэша, S3 для файлов. Архитектура данных стала набором, а не одним выбором на весь проект.

---

Глава 15. Наблюдаемость как часть архитектуры

Почему логов недостаточно

В монолите grep по одному файлу часто находил причину. В twenty-service системе запрос проходит через gateway, auth, три сервиса и очередь — без корреляции вы видите двадцать несвязанных stack trace.

Три столпа Observability

1. Logs — дискретные события с контекстом (structured logging, JSON).
2. Metrics — агрегаты во времени (RPS, latency p99, error rate).
3. Traces — путь одного запроса через все hop'ы (trace id в заголовках).

Инструменты

Prometheus + Grafana — метрики и дашборды. OpenTelemetry — стандарт инструментирования. Jaeger, Tempo — визуализация трейсов. Без этого микросервисы и serverless слепы в продакшене.

Наблюдаемость закладывают при проектировании — не «добавим после инцидента».

---

Глава 16. Искусственный интеллект меняет архитектуру

Новые требования

Приложения с LLM не сводятся к одному HTTP-вызову. Нужны: управление промптами и версиями моделей, лимиты токенов и стоимости, кэш эмбеддингов, приватность данных, fallback при недоступности провайдера.

Новые компоненты

• Embeddings — векторное представление текста для семантического поиска.
• Retrieval — выбор релевантных фрагментов из базы знаний.
• RAG (Retrieval-Augmented Generation) — модель отвечает с опорой на ваши документы, а не только на обучение.

Типичная схема AI-приложения

[Клиент] → [API / Orchestrator] → [LLM API]
                ↓                        ↑
         [Vector DB] ← [Embeddings pipeline]
                ↓
         [Document store / CRM / wiki]

Оркестратор решает: когда вызвать инструмент, когда искать в векторной БД, когда эскалировать человеку. Векторные хранилища (pgvector, Pinecone, Qdrant, Weaviate) стали таким же архитектурным выбором, как Redis десять лет назад.

---

Глава 17. Какие идеи оказались ошибочными — в контексте

Не «технологии-провалы», а неуместное применение:

Микросервисы для маленьких проектов. Три разработчика не получают выгоду от независимого деплоя пяти сервисов; получают операционный ад.

Чрезмерная распределённость. Синхронные цепочки из семи HTTP-вызовов на один клик пользователя; saga без компенсаций; «всё в Kafka» без потребителей.

Преждевременная оптимизация. Шардирование БД при тысяче пользователей; multi-region до product-market fit.

Слепое копирование Big Tech. Ваш стартап не Netflix; их решения оплачены их масштабом боли.

Ошибка не в идее микросервиса или SPA — в несовпадении идеи с размером команды, бюджетом и реальной нагрузкой.

---

Глава 18. Что нас ждёт в следующие 10 лет

AI-assisted development — агенты генерируют код и инфраструктуру; архитектор фокусируется на границах модулей и ограничениях, а не на бойлерплейте.

Edge computing — логика ближе к пользователю (Cloudflare Workers, Deno Deploy); меньше round-trip, жёстче лимиты CPU.

WebAssembly — тяжётые вычисления и порты существующих библиотек в браузере без полной отдачи логики на сервер.

Локальные AI-модели — приватность и офлайн; гибрид «малая модель на устройстве + большая в облаке по необходимости».

Агентные системы — цепочки автономных шагов с инструментами; новые требования к безопасности, аудиту и human-in-the-loop.

Self-healing applications — автоматический rollback, canary на уровне платформы, remediation runbook'и от ИИ при типовых инцидентах.

Прогнозы размыты; направление ясно: больше автоматизации рутины, больше гибридных моделей (edge + cloud, local LLM + API, SSR + islands), больше давления на простоту там, где сложность не окупается.

---

Заключение

Главный урок двадцати лет

Идеальной архитектуры не существует. Каждая — компромисс между скоростью разработки, стоимостью владения, UX, надёжностью и скоростью изменений бизнеса. То, что сегодня называют «legacy», вчера было правильным ответом на вчерашние ограничения.

Как выбирать архитектуру сегодня

1. Размер команды — монолит или modular monolith для малой группы; микросервисы при доказанной боли координации.
2. Бюджет — managed-сервисы vs собственный K8s; стоимость инцидентов vs стоимость облака.
3. Бизнес-задачи — контентный сайт, SaaS, маркетплейс, real-time — у каждого разный профиль нагрузки и SEO.
4. Траектория роста — закладывайте границы модулей рано; резать на сервисы позже, когда границы ясны.

Финальная мысль

Самые устойчивые проекты редко строят на самой модной архитектуре. Они строят на самой простой архитектуре, которая решает текущую задачу и не мешает эволюционировать завтра. История веба — не гонка за хайпом, а череда осмысленных ответов на меняющиеся ограничения. Следующий ваш выбор стека будет правильным, если вы честно назовёте эти ограничения — до того, как откроете README очередного фреймворка.