Архитектуры чата: обзор подходов

Перед началом: Модуль 1 (введение в Serverless, сервисы Yandex Cloud). Инструменты: — (концептуальный модуль). Время: ~6 ч.

🔥 Инцидент: война за архитектуру

Команда из четырёх человек выбирает архитектуру для нового чата. И каждый тянет одеяло на себя.

CTO, приехавший из enterprise, хочет «как в Google»: Managed Kubernetes с HPA, canary-деплоем и service mesh — «это правильно и масштабируемо». Финдиректор смотрит в бюджет и требует VPS: «зачем платить за оркестрацию, когда один сервер за ₽2000/мес всё потянет?». Разработчик-лид хочет «быстро и без ops»: Serverless — «деплой за минуту, платим за вызовы». DevOps молча готовит resignation letter.

Кто прав? Зависит от NFR (нефункциональных требований): бюджета, прогнозируемой нагрузки, размера команды, time-to-market. В этом модуле честно сравним bare metal, VPS, LB+VM, Kubernetes и Serverless — и выберем подход, который уложится в free-tier.

📖 Теория

Прежде чем проектировать чат, сравним варианты развёртывания — от собственного железа до serverless — и выберем подход, который укладывается в free-tier Yandex Cloud. Критерии, по которым сравниваем, — это требования самого чата.

Что требуется от чат-комнаты

• Real-time доставка — сообщения доходят за доли секунд.
• Персистентность — история не теряется при сбое.
• Fan-out — одно сообщение доставляется многим участникам комнаты.
• Масштабирование — от 1 до тысяч пользователей без переделок.
• Офлайн/PWA — работа при потере сети, push-уведомления.
• Низкая стоимость простоя — платим за использование, а не «за включённый сервер».

Эти же критерии применим к каждой архитектуре ниже.

1. Bare Metal — монолит на физическом сервере

Всё на одном железе: Nginx, Go-монолит (Auth/Chat/WebSocket в одном процессе), БД — на том же сервере.

• Плюсы: полный контроль, предсказуемые задержки, нет «чужих» лимитов.
• Минусы: единая точка отказа, масштабирование только вручную (купить сервер), ручные OS-обновления, нет отказоустойчивости.
• Когда выбирать: жёсткий compliance, нельзя в облако, нужна максимальная предсказуемость latency.
• В Yandex Cloud: ❌ bare metal не предоставляется.

2. VDS / одна виртуальная машина (Compute Cloud)

Один инстанс Compute Cloud с Go-монолитом + отдельная managed-БД (PostgreSQL).

• Плюсы: проще bare metal, дешёвый старт, знакомая модель.
• Минусы: 1 VM = единая точка отказа, масштабирование только вручную (добавить VM + LB), платёж 24/7 за VM и managed-БД — даже когда чатом не пользуются.
• Когда выбирать: маленький прогнозируемый проект, бюджет ограничен, нет нагрузки.
• Free-tier: ❌ VM и managed-БД платятся всегда.

3. Load Balancer + пул VM

Application Load Balancer (L7) распределяет трафик по N виртуальным машинам; общие Managed PostgreSQL и Managed Redis для сессий и fan-out; статика — в Object Storage.

• Плюсы: нет SPOF на приложении, горизонтальное масштабирование добавлением VM, ALB поддерживает WebSocket.
• Минусы: платёж 24/7 за все VM + managed Redis/PostgreSQL, сложнее деплой и синхронизация состояния между машинами.
• Когда выбирать: постоянная предсказуемая нагрузка, нужна отказоустойчивость без оверхеда serverless.
• Free-tier: ❌ кластер VM и Redis платятся всегда.

4. Managed Kubernetes

Кластер Managed Service for Kubernetes: Ingress (ALB), Deployment’ы auth/chat/ws с репликами, HPA по CPU/RPS, canary-деплой; state — в Managed PostgreSQL и Redis.

• Плюсы: зрелая оркестрация, автоскейлинг (HPA/Cluster Autoscaler), отказоустойчивость, canary/blue-green.
• Минусы: высокий порог входа, нужен DevOps, сложнее отлаживать WebSocket из-за ephemeral-подов.
• Когда выбирать: много микросервисов, enterprise/compliance-требования, команда с экспертизой.
• Free-tier: ❌ мастер + worker-ноды платятся всегда; нужен оверсот для резерва.

5. Serverless (FaaS + BaaS)

API Gateway → Cloud Functions (auth, ingestion) → YDB + YMQ → Broadcast Function → YDS → Serverless Container (WebSocket Gateway); статика — в Object Storage.

• Плюсы: масштаб 0 → N, оплата за фактическое использование, нет управления серверами, высокая доступность из коробки.
• Минусы: cold start (~0.5 с), функции stateless (состояние в YDB/очередях), лимиты времени выполнения, асинхронная задержка доставки через очередь (1–2 с).
• Когда выбирать: MVP/стартап, непредсказуемая нагрузка, команда 1–2 человека, критичен time-to-market.
• Free-tier: ✅ масштабируется в ноль и имеет щедрые бесплатные лимиты — единственный подход, укладывающийся в ₽0/мес при малом трафике.

Что доступно в Yandex Cloud

Сравнительная матрица

Фильтр: уложиться в free-tier

Главная цель курса — запустить рабочий чат бесплатно. Применим этот фильтр:

Из всех подходов только serverless масштабируется в ноль и имеет бесплатные лимиты, покрывающие малый трафик (~20 пользователей, ~1000 сообщений/день → ₽0/мес).

Решение

Для курса выбран serverless, потому что:

• ✅ Pay-as-you-go — ₽0 при малом трафике (free-tier полностью покрывает MVP).
• ✅ Автоматическое масштабирование без управления серверами.
• ✅ Высокая доступность из коробки.
• ✅ Быстрый старт и короткий time-to-market.

Когда стоит уйти с serverless (отдельная тема курса): постоянная высокая нагрузка (>1000 msg/сек), требование latency <20ms, stateful long-lived соединения в огромных количествах — тогда WS-воркеры выносят в Kubernetes, а очереди заменяют/дополняют Kafka. Но это фаза масштабирования, а не MVP.

Компромиссы (Trade-offs)

Вывод модуля: для чата на free-tier с непредсказуемой нагрузкой выбираем Serverless. Когда нагрузка станет постоянной и высокой — переосмыслим (Модуль 10).

В следующем модуле разберём детальный дизайн выбранной serverless-архитектуры: компоненты, поток данных, почему нужны очереди (YMQ/YDS) и бюджет free-tier.

🧩 Проверь себя

🔗 Мостик к Модулю 3

Архитектура выбрана: serverless под free-tier. Но «выбрать serverless» — это не ответ, а начало дизайна: какие именно сервисы, как они связаны, где состояние, где очереди, как переживать сбои. В Модуле 3 — детальный дизайн serverless-чата: 10 компонентов, поток данных, развязка через YMQ/YDS и бюджет free-tier по цифрам.