System Design

🎯 Основы системного дизайна

Что такое System Design

System Design — проектирование архитектуры больших распределённых систем, способных обрабатывать миллионы запросов и терабайты данных. Включает выбор технологий, паттернов взаимодействия компонентов и стратегий масштабирования.

High-Level vs Low-Level Design

• High-Level Design: общая архитектура системы, основные компоненты, потоки данных
• Low-Level Design: детальная реализация отдельных модулей, API, схемы БД

Ключевые принципы

• Scalability (масштабируемость) — способность справляться с ростом нагрузки
• Reliability (надёжность) — система работает корректно даже при сбоях
• Availability (доступность) — процент времени работоспособности системы
• Fault Tolerance (отказоустойчивость) — продолжение работы при частичных сбоях

📊 Оценка нагрузки и требований

Основные метрики

• QPS/RPS (Queries/Requests Per Second) — запросов в секунду
• Peak load — пиковая нагрузка (обычно в 3-5 раз выше средней)
• Storage — объём данных для хранения
• Bandwidth — пропускная способность сети

CAP теорема

Из трёх свойств можно гарантировать только два:

• Consistency — все узлы видят одинаковые данные одновременно
• Availability — система отвечает на запросы
• Partition tolerance — работа при разделении сети

🏗️ Архитектурные паттерны

Monolith vs Microservices

Monolith — единое приложение, простое в разработке и деплое, но сложное в масштабировании отдельных частей.

Microservices — набор небольших независимых сервисов, каждый со своей БД и зоной ответственности. Плюсы: независимое масштабирование, технологическое разнообразие. Минусы: сложность в координации, network latency.

Service-Oriented Architecture (SOA)

Более тяжёлый подход по сравнению с микросервисами, с общими БД и бизнес-логикой.

Event-Driven Architecture

Компоненты взаимодействуют через события. Слабая связанность, но сложность в отслеживании потоков данных.

⚖️ Load Balancing (Балансировка нагрузки)

Типы балансировщиков

• Layer 4 (Transport layer) — маршрутизация по IP и портам
• Layer 7 (Application layer) — маршрутизация по содержимому HTTP-запросов

Алгоритмы балансировки

• Round Robin — поочерёдное распределение запросов
• Weighted Round Robin — с учётом весов серверов
• Least Connections — на сервер с наименьшим числом активных соединений
• IP Hash — по хешу IP клиента (sticky sessions)

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

• HAProxy — высокопроизводительный L4/L7 балансировщик
• Nginx — веб-сервер с функциями балансировки
• AWS ALB/NLB — облачные решения Amazon

💾 Стратегии кеширования

Уровни кеширования

1. Browser cache — кеш браузера клиента
2. CDN — географически распределённая сеть кеширования
3. Application cache — кеш внутри приложения (Redis, Memcached)
4. Database cache — кеш на уровне БД

Паттерны кеширования

• Cache-aside — приложение управляет кешем вручную
• Write-through — запись одновременно в кеш и БД
• Write-behind — асинхронная запись из кеша в БД
• Refresh-ahead — проактивное обновление кеша перед истечением TTL

Cache Invalidation

• TTL (Time To Live) — время жизни записи в кеше
• Write-through invalidation — удаление при изменении данных
• Event-based invalidation — по событиям изменения данных

🗄️ Базы данных и хранение

SQL vs NoSQL

SQL БД (PostgreSQL, MySQL) — ACID-транзакции, строгая схема, сложные запросы NoSQL БД — горизонтальное масштабирование, гибкая схема, eventual consistency

Типы NoSQL

• Document (MongoDB) — хранение JSON-подобных документов
• Key-Value (Redis, DynamoDB) — простейшая модель ключ-значение
• Column-family (Cassandra) — данные группируются по столбцам
• Graph (Neo4j) — для связанных данных и графовых запросов

Database Scaling

Vertical scaling — увеличение мощности сервера Horizontal scaling — добавление серверов:

• Master-Slave replication — один master для записи, несколько slave для чтения
• Sharding — разделение данных по разным серверам по ключу

Distributed Transactions

• Two-Phase Commit (2PC) — координатор подготавливает все участники, затем фиксирует
• Saga pattern — цепочка локальных транзакций с компенсирующими действиями

🚀 Масштабирование

Horizontal vs Vertical

• Vertical — увеличение CPU/RAM/SSD существующих серверов
• Horizontal — добавление новых серверов в кластер

Auto-scaling

• Reactive — реакция на текущую нагрузку (CPU, memory usage)
• Predictive — на основе исторических данных и ML-моделей
• Scheduled — по расписанию (например, перед чёрной пятницей)

Stateless vs Stateful

Stateless services — не хранят состояние между запросами, легко масштабируются Stateful services — хранят состояние, требуют sticky sessions или внешнее хранилище состояния

📡 Межсервисное взаимодействие

Синхронное взаимодействие

• REST API — HTTP-запросы с JSON, простота и универсальность
• GraphQL — гибкие запросы, получение только нужных данных
• gRPC — бинарный протокол на HTTP/2, высокая производительность

Асинхронное взаимодействие

• Message Queues — очереди сообщений для разделения производителей и потребителей
• Event Streaming — потоки событий в реальном времени

Message Brokers

• Apache Kafka — высокопроизводительная платформа для стриминга событий
• RabbitMQ — брокер сообщений с гарантией доставки
• Apache Pulsar — multi-tenant платформа с геораспределением

API Gateway

Единая точка входа для всех клиентских запросов:

• Маршрутизация к микросервисам
• Аутентификация и авторизация
• Rate limiting и throttling
• Мониторинг и логирование

🛡️ Безопасность

Authentication vs Authorization

• Authentication — проверка подлинности (кто это?)
• Authorization — проверка прав доступа (что может делать?)

Методы аутентификации

• JWT (JSON Web Token) — самодостаточные токены с подписью
• OAuth 2.0 — стандарт авторизации для третьих сторон
• Session-based — серверные сессии с cookies

Security Best Practices

• HTTPS everywhere — шифрование всего трафика
• Input validation — валидация всех входящих данных
• SQL injection prevention — подготовленные запросы
• Rate limiting — ограничение частоты запросов

📈 Мониторинг и наблюдаемость

Pillars of Observability

• Metrics — числовые показатели производительности
• Logs — структурированные записи событий
• Traces — путь запроса через систему

Key Metrics

• SLA/SLO/SLI — соглашения и показатели уровня сервиса
• MTTR (Mean Time To Recovery) — среднее время восстановления
• MTBF (Mean Time Between Failures) — среднее время между сбоями

Инструменты мониторинга

• Prometheus + Grafana — сбор метрик и визуализация
• ELK Stack (Elasticsearch, Logstash, Kibana) — централизованное логирование
• Jaeger/Zipkin — распределённая трассировка

🎪 Популярные системы в System Design

URL Shortener (Сокращатель URL)

Проблема: как создать систему типа bit.ly для миллиардов URL

Ключевые компоненты:

• Base62 encoding для коротких URL
• Cache для популярных ссылок
• Rate limiting для предотвращения спама
• Analytics для сбора статистики переходов

Chat System

Проблема: дизайн WhatsApp/Telegram для миллионов пользователей

Ключевые компоненты:

• WebSocket connections для real-time сообщений
• Message queues для offline пользователей
• Push notifications
• End-to-end encryption

Social Media Feed

Проблема: лента новостей Twitter/Instagram

Ключевые компоненты:

• Fan-out strategies (push vs pull model)
• Timeline generation algorithms
• Content recommendation ML models
• Media storage и CDN

Design Search Engine

Проблема: поисковая система типа Google

Ключевые компоненты:

• Web crawling и indexing
• Inverted index для быстрого поиска
• PageRank алгоритм ранжирования
• Distributed storage для индексов

🎯 Подготовка к собеседованию

Структура ответа

1. Clarify requirements — уточнить функциональные и нефункциональные требования
2. Estimate scale — оценить объёмы данных и нагрузку
3. High-level design — нарисовать общую архитектуру
4. Deep dive — детализировать критичные компоненты
5. Scale the design — обсудить масштабирование и узкие места

Частые вопросы

• Как спроектировать систему для 100M пользователей?
• Как обеспечить consistency в распределённой системе?
• Как выбрать между SQL и NoSQL для конкретной задачи?
• Как обработать hot spots в sharded database?
• Как спроектировать rate limiter?

Характеристики распределенных систем

⚡ Latency vs Throughput

Latency (Задержка)

Время отклика — сколько времени занимает обработка одного запроса от отправки до получения ответа.

Измеряется в миллисекундах (ms):

• Отличная задержка: < 100ms
• Приемлемая: 100-500ms
• Плохая: > 1000ms

Факторы влияния:

• Географическое расстояние до сервера
• Время обработки в приложении
• Скорость базы данных
• Сетевые задержки

Throughput (Пропускная способность)

Количество запросов, которые система может обработать в единицу времени.

Измеряется в RPS/QPS (requests/queries per second):

• Веб-приложение: 1000-10000 RPS
• High-load система: 100000+ RPS

Факторы влияния:

• Количество серверов
• Эффективность алгоритмов
• Пропускная способность БД
• Сетевая инфраструктура

Взаимосвязь Latency и Throughput

Обратная зависимость — улучшение одного параметра часто ухудшает другой:

• Увеличение throughput (больше параллельных запросов) → увеличение latency из-за очередей
• Уменьшение latency (оптимизация обработки) → может снизить общий throughput

Балансировка:

• Connection pooling — переиспользование соединений с БД
• Асинхронная обработка — неблокирующие операции
• Кеширование — быстрый доступ к часто используемым данным

🔄 CAP Theorem

Основные принципы

CAP Theorem утверждает, что в распределенной системе можно гарантировать только два из трех свойств:

Consistency (Согласованность)

Все узлы видят одинаковые данные одновременно

Strong Consistency — любое чтение после записи вернет новое значение:

• Традиционные SQL БД (PostgreSQL, MySQL)
• Блокирующие операции до синхронизации всех узлов

Eventual Consistency — данные станут согласованными со временем:

• NoSQL системы (Cassandra, DynamoDB)
• Более высокая доступность, но возможны временные расхождения

Availability (Доступность)

Система всегда отвечает на запросы (даже если данные могут быть не самыми свежими)

Измерение доступности:

• 99.9% (8.76 часов простоя в год)
• 99.99% (52.56 минут простоя в год)
• 99.999% (5.26 минут простоя в год)

Техники обеспечения:

• Репликация данных на несколько узлов
• Failover механизмы
• Graceful degradation — частичная функциональность при сбоях

Partition Tolerance (Устойчивость к разделению)

Система продолжает работать при разрыве сетевых соединений между узлами

Сценарии разделения сети:

• Обрыв кабелей между дата-центрами
• Проблемы с маршрутизацией
• Высокая задержка, превышающая таймауты

Стратегии обработки:

• Quorum-based системы — решения принимаются большинством узлов
• Split-brain prevention — предотвращение конфликтующих лидеров

Практические примеры

CP системы (Consistency + Partition Tolerance):

• MongoDB (с strong consistency)
• Redis Cluster
• Жертвуют доступностью во время network partitions

AP системы (Availability + Partition Tolerance):

• Cassandra
• DynamoDB
• Amazon S3
• Жертвуют согласованностью ради доступности

CA системы (Consistency + Availability):

• Традиционные RDBMS в single-node конфигурации
• Не могут работать в truly distributed окружении

🎯 ACID vs BASE

ACID Properties (для SQL БД)

Atomicity (Атомарность)

Транзакция выполняется полностью или не выполняется вообще

"Все или ничего":

• При сбое во время транзакции все изменения откатываются
• Банковский перевод: деньги списываются И зачисляются, или операция отменяется
• Реализация через rollback механизмы

Consistency (Согласованность)

База данных переходит из одного валидного состояния в другое

Поддержание целостности данных:

• Foreign key constraints
• Check constraints
• Business rules validation
• Предотвращение нарушения ограничений схемы БД

Isolation (Изолированность)

Параллельные транзакции не влияют друг на друга

Уровни изоляции:

• Read Uncommitted — может читать незакоммиченные данные (dirty reads)
• Read Committed — читает только закоммиченные данные
• Repeatable Read — повторные чтения возвращают те же данные
• Serializable — максимальная изоляция, как если бы транзакции выполнялись последовательно

Durability (Долговечность)

Зафиксированные изменения сохраняются навсегда

Гарантии сохранности:

• Запись в постоянное хранилище (диск)
• Write-ahead logging (WAL)
• Replication для защиты от аппаратных сбоев

BASE Properties (для NoSQL БД)

Basically Available (Базовая доступность)

Система остается доступной большую часть времени

Принципы:

• Partial failures допустимы
• Graceful degradation функциональности
• Система может работать в ограниченном режиме

Soft State (Мягкое состояние)

Состояние системы может изменяться со временем без внешних воздействий

Характеристики:

• Данные могут быть несогласованными между узлами
• Нет гарантий snapshot consistency
• Background процессы могут изменять данные для достижения консистентности

Eventually Consistent (Финальная согласованность)

Система станет согласованной через некоторое время

Временные несоответствия:

• Read-after-write может вернуть старые данные
• Разные узлы могут временно иметь разные версии
• Конвергенция к единому состоянию с течением времени

ACID vs BASE - Когда что использовать

ACID подходит для:

• Финансовые операции
• Критически важные бизнес-данные
• Системы с сильными требованиями к консистентности

BASE подходит для:

• Социальные сети, рекомендательные системы
• Аналитические системы
• Системы с высокими требованиями к производительности и доступности

⚖️ Load Balancer (Балансировщик нагрузки)

Назначение

Распределение входящих запросов между несколькими серверами для:

• Предотвращения перегрузки отдельных серверов
• Повышения общей производительности системы
• Обеспечения отказоустойчивости

Типы балансировщиков

Layer 4 (Transport Layer)

Работает на уровне TCP/UDP

Характеристики:

• Принимает решения на основе IP адресов и портов
• Не анализирует содержимое HTTP запросов
• Более быстрая обработка
• Меньше потребление ресурсов

Применение: когда нужна максимальная производительность

Layer 7 (Application Layer)

Работает на уровне HTTP/HTTPS

Характеристики:

• Анализирует содержимое HTTP запросов
• Может маршрутизировать по URL, headers, cookies
• Поддерживает SSL termination
• Больше возможностей для routing логики

Применение: микросервисная архитектура, сложная маршрутизация

Алгоритмы балансировки

Round Robin

Поочередное распределение запросов

• Простейший алгоритм
• Подходит для серверов одинаковой мощности
• Не учитывает текущую нагрузку

Weighted Round Robin

Round Robin с учетом весов серверов

• Мощным серверам назначается больший вес
• Учитывает различия в производительности
• Статическая конфигурация весов

Least Connections

Направление на сервер с наименьшим числом активных соединений

• Учитывает текущую нагрузку
• Подходит для долгих соединений
• Требует отслеживания состояния соединений

IP Hash

Маршрутизация на основе хеша IP клиента

• Обеспечивает sticky sessions
• Один клиент всегда попадает на один сервер
• Полезно для stateful приложений

Health Checks

Мониторинг состояния backend серверов

Типы проверок:

• TCP health check — проверка доступности порта
• HTTP health check — проверка HTTP endpoint'а
• Application health check — проверка готовности приложения

Параметры:

• Interval — частота проверок
• Timeout — время ожидания ответа
• Healthy/Unhealthy threshold — количество успешных/неуспешных проверок

🌐 CDN (Content Delivery Network)

Назначение

Географически распределенная сеть серверов для быстрой доставки контента пользователям

Основные функции:

• Кеширование статического контента рядом с пользователями
• Снижение нагрузки на origin серверы
• Улучшение пользовательского опыта

Принцип работы

Edge Servers (Граничные серверы)

Серверы, расположенные близко к пользователям

• Кешируют популярный контент
• Обслуживают запросы без обращения к origin
• Automatic failover при недоступности

Cache Hit vs Cache Miss

Cache Hit — контент найден в CDN:

• Быстрая отдача из локального кеша
• Минимальная latency
• Снижение нагрузки на origin

Cache Miss — контент не найден в CDN:

• Запрос перенаправляется на origin сервер
• Контент кешируется для последующих запросов
• Первый запрос может быть медленнее

Стратегии кеширования

Push CDN

Контент загружается в CDN заранее

• Подходит для сайтов с небольшим объемом контента
• Полный контроль над тем, что кешируется
• Требует активного управления кешем

Pull CDN

Контент загружается в CDN по запросу

• Подходит для сайтов с большим объемом контента
• Автоматическое кеширование популярного контента
• Первые запросы могут быть медленнее

Cache Invalidation

Механизмы обновления устаревшего контента

TTL (Time To Live):

• Автоматическое истечение через заданное время
• Подходит для контента с предсказуемым lifecycle

Purge/Invalidate:

• Принудительное удаление из кеша
• Используется при обновлении критически важного контента

💾 Кеширование

Уровни кеширования

Browser Cache

Кеш в браузере пользователя

• HTTP headers (Cache-Control, ETag, Last-Modified)
• Самый быстрый уровень
• Ограниченный размер и контроль

Application Cache

Кеш внутри приложения

• In-memory кеш (Caffeine, Guava Cache)
• Distributed cache (Redis, Memcached)
• Полный контроль над lifecycle

Database Cache

Кеш на уровне базы данных

• Query result cache
• Buffer pool для страниц данных
• Автоматическое управление СУБД

Паттерны кеширования

Cache-Aside (Lazy Loading)

Приложение управляет кешем вручную

Алгоритм:

1. Проверить кеш
2. Если данных нет — запросить из БД
3. Сохранить в кеш
4. Вернуть данные

Плюсы: простота реализации, кешируется только нужное Минусы: дополнительная логика в приложении

Write-Through

Синхронная запись в кеш и БД

Алгоритм:

1. Запись в кеш
2. Запись в БД
3. Подтверждение успеха

Плюсы: данные всегда свежие Минусы: увеличенная latency записи

Write-Behind (Write-Back)

Асинхронная запись из кеша в БД

Алгоритм:

1. Запись в кеш
2. Немедленное подтверждение
3. Фоновая запись в БД

Плюсы: быстрые записи, пакетная обработка Минусы: риск потери данных при сбое

Refresh-Ahead

Проактивное обновление кеша

Алгоритм:

1. Мониторинг expiration time
2. Обновление перед истечением TTL
3. Избежание cache miss

Плюсы: предсказуемая производительность Минусы: дополнительная нагрузка на БД

Cache Eviction Policies

LRU (Least Recently Used)

Удаление наиболее давно используемых данных

• Хорошо для временной локальности доступа
• Популярный выбор для большинства случаев

LFU (Least Frequently Used)

Удаление наименее часто используемых данных

• Учитывает частоту, а не время доступа
• Лучше для долгоживущих популярных данных

FIFO (First In, First Out)

Удаление в порядке поступления

• Простейшая реализация
• Не учитывает паттерны доступа

📈 Horizontal vs Vertical Scaling

Vertical Scaling (Масштабирование вверх)

Определение

Увеличение мощности существующего сервера

• Добавление CPU, RAM, SSD
• Upgrade до более мощного железа
• Единый узел с возросшей производительностью

Преимущества

Простота:

• Не требует изменений в архитектуре приложения
• Нет сложности распределенных систем
• Простое управление и мониторинг

Consistency:

• Отсутствие проблем с распределенными транзакциями
• Единое состояние системы
• ACID свойства сохраняются

Недостатки

Ограничения роста:

• Физические ограничения железа
• Дорогостоящие high-end серверы
• Single point of failure

Downtime:

• Необходимость остановки для upgrade
• Планируемые окна обслуживания

Применение

Подходит для:

• Monolith приложений
• Систем с сильными ACID требованиями
• Начальных стадий развития продукта

Horizontal Scaling (Масштабирование в ширину)

Определение

Добавление новых серверов в кластер

• Распределение нагрузки между узлами
• Параллельная обработка запросов
• Увеличение общей пропускной способности

Преимущества

Неограниченный рост:

• Теоретически бесконечное масштабирование
• Линейное увеличение производительности
• Экономичные commodity серверы

Fault Tolerance:

• Отказ одного узла не критичен
• Автоматическое перераспределение нагрузки
• Higher availability

Гибкость:

• Auto-scaling по требованию
• Pay-as-you-grow модель в облаке

Недостатки

Сложность архитектуры:

• Distributed systems challenges
• Network latency между узлами
• Сложная отладка и мониторинг

Consistency проблемы:

• CAP theorem ограничения
• Eventual consistency
• Distributed transactions сложность

Применение

Подходит для:

• Микросервисной архитектуры
• Stateless приложений
• High-load систем с веб-трафиком

Database Scaling

Vertical Database Scaling

Увеличение мощности DB сервера

• Больше RAM для buffer pool
• Быстрые SSD для I/O операций
• Мощный CPU для query processing

Ограничения:

• Максимальный размер instance
• Дорогостоящие enterprise решения

Horizontal Database Scaling

Read Replicas

Создание read-only копий БД

• Master для записи, slaves для чтения
• Асинхронная репликация
• Горизонтальное масштабирование read операций

Sharding

Разделение данных по multiple БД

• Partition по ключу (user_id, region)
• Каждый shard содержит subset данных
• Требует shard-aware приложение

Challenges:

• Cross-shard queries сложность
• Rebalancing при росте данных
• Hot spots при неравномерном распределении

Выбор стратегии масштабирования

Начальная стадия (< 1000 пользователей)

Vertical scaling:

• Простота разработки и deployment
• Один сервер для всего стека
• Быстрый time-to-market

Рост продукта (1000-100000 пользователей)

Hybrid подход:

• Vertical scaling для БД
• Horizontal scaling для app серверов
• Load balancer + multiple instances

High-load системы (100000+ пользователей)

Horizontal scaling:

• Микросервисная архитектура
• Database sharding/partitioning
• Auto-scaling и cloud-native решения

Базовые компоненты распределенных систем

🚪 API Gateway

Назначение

Единая точка входа для всех клиентских запросов в микросервисную архитектуру. Выступает как proxy между клиентами и backend сервисами.

Основные функции

Routing (Маршрутизация)

Направление запросов к соответствующим микросервисам

• URL-based routing: /users/* → User Service
• Header-based routing: версионирование API
• Canary deployments: процент трафика на новую версию

Authentication & Authorization

Централизованная аутентификация и авторизация

• JWT token validation
• OAuth 2.0 integration
• API key management
• Role-based access control (RBAC)

Rate Limiting & Throttling

Ограничение частоты запросов

• Per-user rate limits
• Per-API endpoint limits
• Burst handling
• Graceful degradation при превышении лимитов

Request/Response Transformation

Модификация данных между клиентом и сервисами

• Protocol translation (REST ↔ GraphQL ↔ gRPC)
• Request/Response mapping
• Data format conversion
• Payload validation

Cross-Cutting Concerns

Общие задачи для всех сервисов

• Logging и audit trail
• Metrics collection
• CORS handling
• SSL termination

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

Kong

Open-source API Gateway с plugin архитектурой

• Nginx-based, высокая производительность
• Rich ecosystem of plugins
• Database-backed конфигурация

AWS API Gateway

Managed сервис от Amazon

• Serverless integration с Lambda
• Built-in monitoring и analytics
• Pay-per-request модель

Zuul (Netflix)

Java-based gateway от Netflix

• Spring Cloud integration
• Dynamic routing capabilities
• Circuit breaker pattern support

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

Преимущества:

• Централизованное управление cross-cutting concerns
• Упрощение клиентской логики
• Единый интерфейс для мониторинга

Недостатки:

• Single point of failure
• Additional network hop (increased latency)
• Potential bottleneck при высокой нагрузке

🌐 Web Servers vs App Servers

Web Server

Назначение

Обработка HTTP запросов и отдача статического контента

• HTML, CSS, JavaScript файлы
• Изображения, видео, документы
• Proxy requests к application серверам

Основные функции

Static Content Serving:

• Эффективная отдача файлов с диска
• HTTP caching headers
• Compression (gzip, brotli)

Reverse Proxy:

• Forwarding requests к backend серверам
• Load balancing между app instances
• SSL termination

Security:

• DDoS protection
• Rate limiting
• IP filtering

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

Nginx

High-performance web server и reverse proxy

• Event-driven архитектура
• Низкое потребление памяти
• Excellent static file performance
• Rich configuration options

Apache HTTP Server

Традиционный web server с модульной архитектурой

• Process/thread-based модель
• Huge ecosystem of modules
• .htaccess configuration support

Application Server

Назначение

Выполнение бизнес-логики приложений

• Обработка динамических запросов
• Database interactions
• Business rules execution
• API endpoints

Основные функции

Dynamic Content Generation:

• Server-side rendering
• API responses
• Database query processing

Application Runtime:

• JVM management (для Java)
• Memory management
• Thread pooling
• Connection pooling

Enterprise Features:

• Transaction management
• Security contexts
• Resource injection
• Clustering support

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

Tomcat

Lightweight Java servlet container

• Embedded в Spring Boot applications
• Simple deployment model
• Good для microservices

Undertow

High-performance web server от JBoss

• Non-blocking I/O
• Low memory footprint
• Embeddable в Java applications

WildFly (JBoss)

Full Java EE application server

• Complete Java EE stack
• Clustering и high availability
• Enterprise-grade features

Web Server + App Server Architecture

Типичная схема развертывания

Nginx (Web Server) → Tomcat (App Server) → Database

Nginx обрабатывает:

• Static content (CSS, JS, images)
• SSL termination
• Load balancing
• Caching

Tomcat обрабатывает:

• Java application logic
• Database connections
• API endpoints
• Session management

Преимущества разделения

• Performance: web server оптимизирован для статики
• Security: дополнительный уровень защиты
• Scalability: независимое масштабирование компонентов
• Flexibility: возможность использования разных технологий

🗄️ Database (SQL vs NoSQL)

SQL Databases (Реляционные БД)

Основные характеристики

Structured data с заранее определенной схемой

• Tables с rows и columns
• Foreign key relationships
• ACID properties
• SQL query language

ACID Properties

Atomicity: транзакция выполняется полностью или не выполняется вообще Consistency: данные остаются в валидном состоянии Isolation: параллельные транзакции не влияют друг на друга Durability: зафиксированные изменения сохраняются навсегда

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

PostgreSQL

Advanced open-source реляционная БД

• JSON/JSONB support
• Advanced indexing (GIN, GiST)
• Full-text search
• Extensible architecture

Применение: сложные аналитические запросы, финансовые системы

MySQL

Популярная open-source БД

• High performance для read-heavy workloads
• Strong replication capabilities
• Wide ecosystem support

Применение: веб-приложения, content management systems

Oracle Database

Enterprise-grade БД с rich feature set

• Advanced analytics
• Partitioning capabilities
• Enterprise security features

Применение: large enterprise applications, критически важные системы

Когда использовать SQL

• Сложные relationships между данными
• Необходимость ACID транзакций
• Structured reporting и analytics
• Regulatory compliance требования

NoSQL Databases

Document Databases

MongoDB

Document-oriented БД с JSON-like документами

Характеристики:

• Flexible schema
• Rich query language
• Horizontal scaling через sharding
• Built-in replication

Применение: content management, catalog systems, user profiles

Пример структуры данных:

{
  "_id": "user123",
  "name": "John Doe", 
  "preferences": {
    "theme": "dark",
    "notifications": ["email", "push"]
  }
}

Key-Value Stores

Redis

In-memory key-value store с persistence опциями

Характеристики:

• Sub-millisecond latency
• Rich data structures (strings, hashes, lists, sets)
• Pub/Sub messaging
• Lua scripting support

Применение: caching, session storage, real-time analytics

DynamoDB (AWS)

Managed NoSQL БД с guaranteed performance

Характеристики:

• Single-digit millisecond latency
• Automatic scaling
• Built-in security
• Global tables для multi-region

Применение: mobile apps, web applications, gaming

Column-Family

Cassandra

Distributed БД для handling large amounts of data

Характеристики:

• Linear scalability
• No single point of failure
• Tunable consistency
• Multi-datacenter replication

Применение: time-series data, IoT applications, messaging systems

Graph Databases

Neo4j

Graph БД для connected data

Характеристики:

• Native graph storage
• Cypher query language
• ACID compliance
• Rich visualization tools

Применение: social networks, recommendation engines, fraud detection

Выбор между SQL и NoSQL

Используйте SQL когда:

• Сложные relationships и joins
• ACID транзакции критичны
• Structured reporting
• Established schema

Используйте NoSQL когда:

• Rapid development и schema changes
• Horizontal scaling requirements
• Large volumes of unstructured data
• High availability важнее consistency

💾 Cache (Redis vs Memcached)

Назначение кеширования

Временное хранение часто используемых данных в быстром доступе для уменьшения latency и снижения нагрузки на основные системы хранения.

Redis

Основные характеристики

Advanced in-memory data structure store

• Поддержка сложных типов данных
• Persistence опции
• Pub/Sub messaging
• Lua scripting

Типы данных

Strings: простые key-value пары Hashes: объекты с полями Lists: упорядоченные списки строк Sets: неупорядоченные уникальные значения Sorted Sets: sets с score для сортировки Streams: append-only log структуры

Advanced Features

Persistence

RDB Snapshots: point-in-time копии данных на диск AOF (Append Only File): лог всех write операций Hybrid persistence: комбинация RDB + AOF

Replication

Master-Slave replication: автоматическая синхронизация данных Redis Cluster: automatic sharding и high availability Redis Sentinel: monitoring и automatic failover

Pub/Sub

Message broadcasting между клиентами

• Channel-based messaging
• Pattern matching subscriptions
• Real-time notifications

Применение Redis

• Session storage: пользовательские сессии
• Caching: результаты database queries
• Real-time analytics: counters, leaderboards
• Message broker: pub/sub scenarios
• Rate limiting: sliding window counters

Memcached

Основные характеристики

Simple in-memory key-value cache

• Только string values
• No persistence
• Multi-threaded architecture
• LRU eviction policy

Преимущества

Simplicity: минималистичный design Performance: optimized для get/set операций Memory efficiency: lower overhead per item Multi-threading: better CPU utilization

Ограничения

No persistence: данные теряются при restart Simple data types: только strings No replication: manual sharding required Limited features: no scripting, pub/sub

Применение Memcached

• Web page caching: результаты рендеринга
• Database query results: простые cache scenarios
• Session storage: при использовании external persistence
• Object caching: serialized application objects

Redis vs Memcached: Сравнение

Выбирайте Redis когда:

• Нужны сложные data structures
• Требуется persistence
• Необходимы advanced features (pub/sub, scripting)
• High availability критична

Выбирайте Memcached когда:

• Простые caching потребности
• Максимальная производительность для get/set
• Ограниченная память
• Multi-threaded applications

Cache Patterns

Cache-Aside (Lazy Loading)

Приложение управляет кешем

1. Проверка кеша
2. Cache miss → запрос к БД
3. Сохранение в кеш
4. Возврат данных

Write-Through

Синхронная запись в кеш и БД

• Всегда актуальные данные в кеше
• Increased write latency
• Good для read-heavy workloads

Write-Behind

Асинхронная запись из кеша в БД

• Быстрые write операции
• Risk of data loss
• Batch processing в БД

📨 Message Broker (Kafka vs RabbitMQ)

Назначение

Middleware для asynchronous communication между сервисами через message passing, обеспечивающий loose coupling и scalability.

Apache Kafka

Основные характеристики

Distributed event streaming platform

• High-throughput message processing
• Fault-tolerant storage
• Horizontal scalability
• Real-time stream processing

Архитектура

Topics и Partitions

Topic: логическая категория сообщений Partition: физическое разделение topic'а для параллелизма Offset: уникальный sequential ID сообщения в partition

Producers и Consumers

Producer: отправляет сообщения в topics Consumer: читает сообщения из topics Consumer Group: набор consumers для parallel processing

Brokers и Clusters

Broker: individual Kafka server Cluster: набор brokers для distributed processing Zookeeper: coordination service (заменяется на KRaft)

Ключевые возможности

Durability

Persistent storage сообщений на диск

• Configurable retention period
• Replication across brokers
• Fault tolerance

Partitioning

Horizontal scaling через разделение данных

• Parallel processing
• Load distribution
• Order preservation внутри partition

Consumer Groups

Load balancing между consumers

• Each message processed by one consumer в группе
• Automatic rebalancing при consumer failures
• Scalable processing

Применение Kafka

• Event sourcing: хранение событий изменения состояния
• Log aggregation: централизованный сбор логов
• Stream processing: real-time data pipelines
• Microservices communication: asynchronous messaging
• Data integration: ETL pipelines

RabbitMQ

Основные характеристики

Traditional message broker с rich messaging patterns

• AMQP protocol support
• Message acknowledgments
• Routing flexibility
• Management interface

Архитектура

Exchanges, Queues, Bindings

Exchange: принимает сообщения от producers Queue: хранит сообщения для consumers Binding: правила routing между exchange и queue

Exchange Types

Direct: routing по exact routing key match Topic: pattern-based routing с wildcards Fanout: broadcast ко всем bound queues Headers: routing по message headers

Messaging Patterns

Work Queues

Distribution of tasks между workers

• Round-robin distribution
• Message acknowledgments
• Task persistence

Publish/Subscribe

Broadcasting сообщений multiple consumers

• Fanout exchange
• Temporary queues
• Real-time notifications

Request/Reply

Synchronous communication pattern

• Correlation IDs
• Reply-to queues
• RPC-like behavior

Advanced Features

Message Acknowledgments

Guaranteed message delivery

• Consumer acknowledgments
• Message redelivery on failure
• Dead letter queues

Clustering

High availability setup

• Queue mirroring
• Automatic failover
• Load distribution

Management Interface

Web-based administration

• Queue monitoring
• Performance metrics
• User management

Применение RabbitMQ

• Task queues: background job processing
• Notification systems: email, SMS delivery
• Workflow orchestration: multi-step processes
• Request routing: load balancing requests
• Data synchronization: между системами

Kafka vs RabbitMQ: Сравнение

Выбирайте Kafka когда:

• High-throughput message streaming
• Event sourcing architecture
• Large-scale data pipelines
• Real-time analytics
• Message ordering важен

Выбирайте RabbitMQ когда:

• Complex routing patterns
• Message acknowledgments критичны
• Request/reply patterns
• Simpler operational model
• Traditional messaging needs

Message Delivery Guarantees

At Most Once

Сообщение доставляется 0 или 1 раз

• Possible message loss
• No duplicate processing
• Lowest latency

At Least Once

Сообщение доставляется 1 или более раз

• No message loss
• Possible duplicates
• Requires idempotent processing

Exactly Once

Сообщение доставляется ровно 1 раз

• No loss, no duplicates
• Complex implementation
• Higher latency

🪣 Object Storage (S3 vs MinIO)

Назначение

Хранение неструктурированных данных (файлы, изображения, видео, документы) с HTTP API доступом и практически неограниченной масштабируемостью.

Amazon S3

Основные характеристики

Highly scalable object storage service

• 99.999999999% (11 9's) durability
• Virtually unlimited storage
• Global accessibility
• Rich ecosystem integration

Архитектура

Buckets и Objects

Bucket: container для objects с уникальным именем Object: файл + metadata, до 5TB размером Key: уникальный identifier объекта внутри bucket

Storage Classes

Standard: frequently accessed data Infrequent Access (IA): less frequent access, lower cost Glacier: long-term archival, retrieval delay Deep Archive: lowest cost, longest retrieval time

Ключевые возможности

Versioning

Сохранение multiple versions одного объекта

• Protection от accidental deletion
• Historical data access
• Rollback capabilities

Cross-Region Replication

Автоматическое копирование между регионами

• Disaster recovery
• Compliance requirements
• Latency optimization

Event Notifications

Triggers при changes в bucket

• Lambda function invocation
• SQS/SNS integration
• Real-time processing

Access Control

Granular permissions management

• Bucket policies
• IAM integration
• Presigned URLs для temporary access

Advanced Features

Lifecycle Policies

Automated data management

• Transition между storage classes
• Automatic deletion after expiration
• Cost optimization

Transfer Acceleration

Faster uploads через CloudFront edge locations

• Global upload optimization
• Consistent performance
• Automatic routing

Multipart Upload

Efficient handling больших файлов

• Parallel uploads
• Resume interrupted transfers
• Better performance

Применение S3

• Static web hosting: CSS, JS, images
• Data archival: long-term backup storage
• Content distribution: integration с CDN
• Data lakes: big data analytics
• Application data storage: user uploads, documents

MinIO

Основные характеристики

High-performance object storage compatible с S3 API

• On-premises deployment
• Kubernetes native
• S3 compatibility
• Open source

Архитектура

Distributed Mode

Multi-node deployment для high availability

• Erasure coding для data protection
• Automatic healing
• No single point of failure

Erasure Coding

Data protection через mathematical redundancy

• Tolerance к multiple drive failures
• Storage efficiency
• Better than RAID

Ключевые возможности

S3 Compatibility

Drop-in replacement для S3

• Same API endpoints
• Compatible с S3 SDKs
• Easy migration

Performance

High-throughput operations

• Parallel processing
• Optimized для modern hardware
• Low latency access

Security

Enterprise-grade security features

• Encryption at rest
• TLS in transit
• Identity management integration

Deployment Options

Standalone Mode

Single server deployment

• Development environments
• Small-scale applications
• Simple setup

Distributed Mode

Multi-server clusters

• Production deployments
• High availability
• Linear scalability

Kubernetes Integration

Cloud-native deployment

• Operator для automated management
• Dynamic scaling
• Persistent volumes

Применение MinIO

• Private cloud storage: on-premises S3 alternative
• Hybrid cloud: bridge между on-prem и cloud
• Edge computing: distributed storage
• Development environments: S3-compatible local storage
• Backup storage: cost-effective alternative

S3 vs MinIO: Сравнение

Выбирайте S3 когда:

• Cloud-first approach
• Global scale requirements
• Rich AWS ecosystem integration
• Managed service preference
• Regulatory compliance features

Выбирайте MinIO когда:

• On-premises deployment requirements
• Cost optimization needs
• Full control над infrastructure
• Kubernetes-native applications
• Hybrid cloud scenarios

🚀 CDN (Content Delivery Network)

Назначение повторно

Географически распределенная сеть серверов для быстрой доставки статического контента пользователям по всему миру.

Архитектура CDN

Edge Locations

Серверы близко к end users

• Reduced latency
• Improved user experience
• Cached content delivery

Origin Servers

Source of truth для контента

• Original content storage
• Fallback при cache miss
• Content updates

Points of Presence (PoPs)

Geographical distribution nodes

• Strategic locations
• Internet exchange points
• ISP partnerships

Популярные CDN providers

CloudFlare

Global CDN с security features

• DDoS protection
• Web application firewall
• DNS services
• Edge computing capabilities

AWS CloudFront

Integrated с AWS ecosystem

• S3 origin integration
• Lambda@Edge
• Real-time metrics
• Certificate management

Azure CDN

Microsoft's content delivery network

• Integration с Azure services
• Custom domains
• Compression options
• Advanced caching rules

CDN Optimization Strategies

Cache Headers

HTTP headers для control caching behavior

• Cache-Control: max-age directives
• ETag: content validation
• Last-Modified: freshness checks

Geographic Optimization

Content placement strategy

• Popular content pre-positioning
• Regional content customization
• Compliance с data residency

Performance Optimization

Speed improvements

• Image optimization
• Minification
• Compression (gzip, brotli)
• HTTP/2 support

Применение CDN

• Static websites: faster page loading
• Media streaming: video delivery optimization
• Software distribution: downloads acceleration
• API acceleration: caching API responses
• Mobile applications: app content delivery

🌍 Сетевые аспекты

DNS (Domain Name System)

Назначение: распределённая система для преобразования доменных имён в IP адреса.

Иерархия DNS

Root servers (корневые серверы):

• 13 кластеров — распределены по всему миру
• Отвечают за домены верхнего уровня — управляют .com, .org, .ru
• Управляются IANA — Управление по присвоению номеров в интернете
• Anycast routing — пользователь попадает на ближайший сервер

TLD (Top-Level Domains - домены верхнего уровня):

• Generic TLD — общие домены .com, .org, .net
• Country-code TLD — национальные домены .ru, .uk, .de
• New gTLD — новые домены .tech, .app, .dev
• Управляются реестрами — разные организации контролируют разные зоны

Authoritative nameservers (авторитетные серверы имён):

• Содержат записи для конкретного домена — знают IP адреса для example.com
• NS records — указывают какие серверы авторитетны для зоны
• SOA record — запись начала зоны полномочий
• Управляются через регистраторов — GoDaddy, Namecheap, REG.RU

Типы DNS записей

A Record:

• IPv4 адрес — прямое сопоставление домена на IP адрес
• Самый распространённый тип — example.com → 192.168.1.1
• TTL (Time To Live) — время кэширования записи

AAAA Record:

• IPv6 адрес — аналог A записи для IPv6
• Растущее использование — с развитием IPv6
• Dual-stack — часто используется вместе с A записью

CNAME Record:

• Canonical Name — псевдоним для другого доменного имени
• Позволяет создавать алиасы — www.example.com → example.com
• Не может сосуществовать — с другими типами записей на том же имени

MX Record:

• Mail Exchange — указывает почтовые серверы для домена
• Приоритеты — числа определяют предпочтительность серверов
• Резервирование — несколько MX записей для надёжности

TXT Record:

• Текстовая информация — произвольные данные
• SPF records — политика отправителей для защиты от спама
• Верификация домена — подтверждение владения для сервисов

DNS Resolution Process (процесс разрешения)

Recursive resolution (рекурсивное разрешение):

1. Клиент запрашивает — браузер хочет узнать IP для example.com
2. Проверка локального кэша — смотрим в кэш DNS resolver'а
3. Запрос к root серверу — спрашиваем кто отвечает за .com
4. Запрос к TLD серверу — спрашиваем .com сервер про example.com
5. Запрос к авторитетному серверу — получаем финальный IP адрес
6. Кэширование с TTL — сохраняем результат на указанное время

DNS caching (кэширование):

• Browser cache — кэш браузера (обычно минуты)
• OS cache — кэш операционной системы
• ISP cache — кэш интернет-провайдера (часы/дни)
• Соблюдение TTL — время жизни записи определяет длительность кэширования

DNS для высокой доступности

Multiple A records:

• Round-robin DNS — несколько IP адресов для одного домена
• Простое распределение нагрузки — браузеры выбирают случайно
• Без проверки здоровья — не знает какие серверы работают
• Проблемы кэширования — клиенты могут кэшировать мёртвый IP

GeoDNS:

• Географическая маршрутизация — разные IP для разных стран/регионов
• Оптимизация задержки — пользователь попадает на ближайший сервер
• Соблюдение законов — данные остаются в нужной юрисдикции
• Интеграция с CDN — часто используется совместно

DNS failover:

• Health monitoring — проверка доступности серверов
• Автоматическое переключение — при падении основного сервера
• Низкий TTL — короткое время кэширования для быстрого переключения
• Managed DNS — Route 53, Cloudflare предоставляют готовые решения

CDN и Anycast

CDN (Content Delivery Network)

Назначение: сеть географически распределённых серверов для быстрой доставки контента пользователям.

Архитектура CDN:

Edge servers (пограничные серверы):

• PoP (Points of Presence) — точки присутствия по всему миру
• Кэш популярного контента — хранят часто запрашиваемые файлы
• Близость к пользователям — минимизируют сетевые задержки
• Пиринг с ISP — прямые соединения с интернет-провайдерами

Origin servers (серверы-источники):

• Source of truth — содержат оригинальные данные
• Cache miss handling — обслуживают запросы при отсутствии в кэше
• Content updates — источник обновлений для всей сети
• Разгрузка — CDN снижает нагрузку на origin

CDN strategies (стратегии):

Push CDN:

• Проактивное кэширование — контент загружается заранее
• Полный контроль — администратор решает что кэшировать
• Высокие затраты на хранение — платим за всё содержимое
• Подходит для статики — редко изменяющийся контент

Pull CDN:

• Реактивное кэширование — контент загружается по требованию
• Автоматическая оптимизация — кэшируется только популярное
• Динамическая адаптация — подстраивается под запросы пользователей
• Лучше для динамики — часто изменяющийся контент

Cache strategies (стратегии кэширования):

Cache-Control headers:

• max-age — время кэширования в секундах
• no-cache — требует проверки актуальности
• private/public — кэшируется браузером или всеми промежуточными серверами
• immutable — файл никогда не изменится (например, с хешем в имени)

Cache invalidation (инвалидация кэша):

• Purge API — программное удаление файлов из кэша
• Version URLs — изменение URL при обновлении файла
• Cache tags — групповое управление связанными файлами
• Webhook triggers — автоматическое обновление при изменениях

Anycast

Назначение: сетевая технология где один IP адрес анонсируется из нескольких географических точек.

Принципы работы:

One IP, multiple locations:

• Одинаковый IP блок — анонсируется из разных датацентров
• BGP routing — протокол маршрутизации определяет ближайший путь
• Shortest path — пакеты автоматически идут к ближайшему серверу
• Automatic failover — при отказе узла трафик переключается

Преимущества:

• Reduced latency — пользователи попадают на географически ближайший сервер
• DDoS mitigation — атака автоматически распределяется между локациями
• Load distribution — естественное распределение нагрузки
• Simple client config — клиенты используют один IP адрес

Use cases (применение):

• DNS root servers — все 13 корневых DNS серверов используют anycast
• CDN edge locations — точки присутствия CDN сетей
• DDoS protection — сервисы защиты от атак
• Global services — единая точка входа для глобальных сервисов

Ограничения:

• Только stateless сервисы — не работает для stateful протоколов
• Session affinity проблемы — пользователь может попасть на разные серверы
• BGP complexity — требует понимания BGP и договорённостей с провайдерами
• ISP зависимость — работа зависит от политик маршрутизации провайдеров

Network Infrastructure (сетевая инфраструктура)

NAT (Network Address Translation)

Назначение: преобразование IP адресов для связи между приватными и публичными сетями.

Типы NAT:

Static NAT:

• Один к одному — постоянное соответствие приватный ↔ публичный IP
• Предсказуемость — всегда одинаковые соответствия
• Ограниченная масштабируемость — нужен отдельный публичный IP для каждого
• Применение — серверы, требующие входящих подключений

Dynamic NAT:

• Пул публичных IP — динамическое назначение из пула адресов
• По мере необходимости — адрес выделяется когда нужен
• Лучшее использование — более эффективное использование публичных IP
• Session-based — соответствие существует только во время сессии

PAT (Port Address Translation):

• Много к одному с портами — множество приватных IP на один публичный
• Port mapping — разные порты для разделения сессий
• Высокая масштабируемость — тысячи внутренних IP на один внешний
• Самый распространённый — стандарт для домашних/офисных сетей

Влияние NAT на приложения:

Направленность соединений:

• Исходящие работают — внутренние клиенты могут инициировать подключения
• Входящие блокируются — внешние клиенты не могут подключиться напрямую
• Port forwarding — явная настройка для входящих подключений
• UPnP/NAT-PMP — автоматическое создание правил

Проблемы приложений:

• Peer-to-peer сложности — проблемы с P2P приложениями
• VoIP проблемы — сложности с голосовой связью
• Gaming — проблемы с многопользовательскими играми
• NAT traversal — техники обхода NAT (STUN, TURN, ICE)

Firewalls (межсетевые экраны)

Назначение: обеспечение сетевой безопасности через фильтрацию трафика по заданным правилам.

Типы файрволов:

Packet filtering:

• Фильтрация 3/4 уровня — по IP адресам, портам, протоколам
• Stateless inspection — каждый пакет анализируется независимо
• Высокая производительность — минимальные задержки
• Ограниченная безопасность — не понимает контекст приложений

Stateful inspection:

• Отслеживание соединений — помнит состояние TCP соединений
• Обратный трафик — автоматически разрешает ответные пакеты
• Лучшая безопасность — понимает контекст соединений
• Session tables — таблицы состояний в памяти

Application layer (7 уровень):

• Deep packet inspection — анализ содержимого пакетов
• Protocol awareness — понимание HTTP, FTP, SMTP протоколов
• Content filtering — блокировка по содержимому
• Высокие накладные расходы — значительное влияние на производительность

NGFW (Next-Generation Firewall):

• Интегрированная безопасность — файрвол + IPS + антивирус + URL фильтрация
• User awareness — правила на основе пользователей и ролей
• Application control — блокировка конкретных приложений
• Threat intelligence — интеграция с базами угроз

Load Balancers (балансировщики нагрузки)

Назначение: распределение входящих запросов между несколькими серверами для масштабируемости и доступности.

Типы балансировщиков:

Layer 4 (транспортный уровень):

• TCP/UDP уровень — работает с IP адресами и портами
• Protocol agnostic — не понимает HTTP или другие протоколы приложений
• Высокая производительность — минимальные задержки
• Примеры — AWS NLB, HAProxy в TCP режиме

Layer 7 (уровень приложений):

• HTTP/HTTPS aware — понимает HTTP протокол и заголовки
• Content-based routing — маршрутизация по URL, заголовкам, cookies
• SSL termination — может расшифровывать HTTPS трафик
• Application intelligence — sticky sessions, health checks
• Примеры — AWS ALB, NGINX, HAProxy в HTTP режиме

Алгоритмы балансировки:

Round Robin:

• По очереди — запросы распределяются последовательно
• Равное распределение — предполагает одинаковую мощность серверов
• Простая реализация — легко понять и настроить
• Не учитывает нагрузку — не знает о текущей загрузке серверов

Weighted Round Robin:

• Учёт мощности серверов — более мощные серверы получают больше запросов
• Пропорциональное распределение — по весам серверов
• Статическая конфигурация — веса настраиваются заранее
• Лучшее использование ресурсов — более эффективно

Least Connections:

• Динамическая нагрузка — направляет на сервер с наименьшими соединениями
• Адаптация в реальном времени — подстраивается под фактическую нагрузку
• Отслеживание соединений — требует мониторинга активных подключений
• Хорошо для долгих соединений — WebSocket, постоянные подключения

IP Hash:

• Session affinity — один клиент всегда попадает на один сервер
• Sticky sessions — поддержка stateful приложений
• Consistent hashing — минимизирует перераспределение при изменении серверов
• Cache locality — лучшее использование локальных кэшей

HTTP Evolution (эволюция HTTP)

HTTP/1.1

Основные характеристики:

• Текстовый протокол — читаемые заголовки и методы
• Persistent connections — переиспользование соединений с Keep-Alive
• Request pipelining — отправка нескольких запросов без ожидания ответов
• Chunked transfer encoding — передача данных частями

Ограничения HTTP/1.1:

Head-of-line blocking:

• Последовательная обработка — запросы обрабатываются по очереди
• Pipeline stalls — медленный запрос блокирует последующие
• Multiple connections — браузеры открывают несколько соединений как обходной путь
• Connection limits — браузеры ограничивают количество одновременных соединений

Header overhead:

• Повторяющиеся заголовки — одинаковые заголовки в каждом запросе
• Отсутствие сжатия — заголовки не сжимаются
• Cookie bloat — большие cookies в каждом запросе
• Расточительность пропускной способности — ненужные накладные расходы

HTTP/2

Ключевые улучшения:

Binary protocol:

• Фреймовая структура — данные передаются в бинарных фреймах
• Multiplexing — множественные потоки в одном соединении
• Эффективный парсинг — быстрее чем текстовый HTTP/1.1
• Лучшее обнаружение ошибок — улучшенная обработка ошибок

Stream multiplexing:

• Одновременные запросы — множественные запросы параллельно
• Нет head-of-line blocking — медленный запрос не блокирует другие
• Stream priorities — приоритизация запросов
• Flow control — управление потоком данных

Header compression (HPACK):

• Алгоритм сжатия — специально для HTTP заголовков
• Static table — предопределённые общие заголовки
• Dynamic table — изученные заголовки во время соединения
• Значительная экономия — особенно для запросов с похожими заголовками

Server Push:

• Проактивная отправка ресурсов — сервер может отправлять ресурсы без запросов
• Оптимизация кэша — push ресурсов которые понадобятся клиенту
• Эффективность пропускной способности — уменьшение количества запросов
• Ограниченное применение — не все браузеры/серверы поддерживают эффективно

HTTP/3 (QUIC)

Революционные изменения:

UDP-based transport:

• QUIC протокол — Quick UDP Internet Connections
• Встроенное шифрование — TLS 1.3 интегрирован в транспорт
• Multiplexing без HOL — истинная независимость потоков
• Connection migration — соединения переживают смену IP адресов

Ключевые преимущества:

Reduced latency:

• 0-RTT connection establishment — мгновенные повторные соединения
• Combined handshake — крипто и транспортное рукопожатие вместе
• Fast recovery — быстрое восстановление от потери пакетов
• Mobile optimization — лучше для нестабильных соединений

True multiplexing:

• Stream-level independence — потеря пакета влияет только на один поток
• No TCP head-of-line — устраняет блокировку на TCP уровне
• Per-stream flow control — детальное управление потоком
• Flexible prioritization — динамические приоритеты потоков

Connection resilience:

• Connection ID — соединения идентифицируются по ID, не IP/порт
• Network changes — переживают переключения WiFi ↔ сотовая связь
• NAT rebinding — устойчивость к изменениям NAT
• Mobile-first design — оптимизация для мобильных сетей

gRPC и Protobuf

gRPC (Google Remote Procedure Call)

Назначение: высокопроизводительный RPC фреймворк для связи между сервисами.

Основные концепции:

Service definition:

• Protocol Buffers — языково-нейтральное определение интерфейсов
• Strong typing — строгая типизация контрактов между сервисами
• Code generation — автоматическая генерация клиентского/серверного кода
• Versioning support — поддержка обратной/прямой совместимости

Transport layer:

• HTTP/2 based — использует возможности HTTP/2
• Multiplexing — множественные RPC вызовы по одному соединению
• Streaming — поддержка двунаправленной потоковой передачи
• Flow control — встроенное управление обратным давлением

Типы RPC:

Unary RPC:

• Запрос-ответ — традиционный паттерн RPC
• Один запрос → один ответ
• Самый простой паттерн — легче всего понять и реализовать
• Применение — CRUD операции, простые запросы

Server streaming:

• Один запрос → поток ответов
• Real-time обновления — сервер отправляет данные клиенту
• Subscription pattern — клиент подписывается на обновления
• Применение — live ленты, уведомления в реальном времени

Client streaming:

• Поток запросов → один ответ
• Bulk операции — клиент отправляет множество элементов
• Aggregation pattern — сервер обрабатывает накопленные данные
• Применение — загрузка файлов, пакетные вставки

Bidirectional streaming:

• Поток запросов ↔ поток ответов
• Full duplex — одновременная отправка/получение
• Interactive pattern — интерактивное взаимодействие в реальном времени
• Применение — чат приложения, онлайн игры в реальном времени

Protocol Buffers (Protobuf)

Назначение: языково-нейтральный, платформо-независимый механизм сериализации.

Преимущества над JSON/XML:

Performance:

• Binary encoding — компактное бинарное представление
• Fast serialization — значительно быстрее парсинга JSON
• Small size — обычно в 3-10 раз меньше JSON
• Schema validation — проверка на этапе компиляции

Type safety:

• Strong typing — типы полей строго контролируются
• Schema evolution — безопасные изменения схемы
• Code generation — генерация типизированных методов доступа
• Backwards compatibility — старые и новые версии могут взаимодействовать

Определение схемы:

syntax = "proto3";

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
  repeated string roles = 4;
}

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc ListUsers(ListUsersRequest) returns (stream User);
}

Правила эволюции схемы:

Безопасные изменения:

• Добавление полей — новые опциональные поля безопасны
• Переименование полей — влияет только на код, не на формат передачи
• Добавление сервисов/методов — обратно совместимо
• Повторное использование номеров полей — избегать повторного использования

Критические изменения:

• Изменение типов полей — несовместимые форматы передачи
• Удаление обязательных полей — ломает старых клиентов
• Изменение номеров полей — ломает совместимость сериализации
• Удаление сервисов/методов — ломает существующих клиентов

gRPC vs REST сравнение

Performance:

• gRPC: бинарный протокол, HTTP/2, меньшие payload'ы
• REST: текстовый, обычно HTTP/1.1, большие JSON payload'ы
• Победитель: gRPC для высокопроизводительных сценариев

Developer experience:

• gRPC: генерация кода, строгая типизация, кривая обучения
• REST: знакомый HTTP, простая отладка, широкий инструментарий
• Победитель: REST для простоты, gRPC для типобезопасности

Экосистема:

• gRPC: растущее применение, специализированные инструменты
• REST: повсеместная поддержка, обширный инструментарий, поддержка браузеров
• Победитель: REST для широкого применения

Когда выбирать:

Выбирайте gRPC когда:

• Microservices communication — внутренняя связь между сервисами
• Performance critical — требования к низкой задержке
• Strong contracts — нужна типобезопасность
• Streaming — двунаправленная потоковая связь в реальном времени

Выбирайте REST когда:

• Public APIs — потребление внешними разработчиками
• Browser clients — прямой доступ из браузера
• Simple CRUD — простые операции с ресурсами
• Caching important — важно кэширование HTTP

Системный дизайн Messenger Avito - Полное решение

Шаг 1: Сбор требований и уточнения (7-10 минут)

Функциональные требования (базовые + дополнительные)

Базовые (из задачи):

• ✅ Отправить сообщение
• ✅ Принять и прочитать сообщение
• ✅ Чаты связаны с объявлениями (инициализация через "Написать")
• ✅ P2P чаты продавец-покупатель
• ✅ Просмотр списка чатов
• ✅ Real-time доставка (<3 секунд)

Дополнительные вопросы интервьюеру:

Q: Нужны ли статусы сообщений (отправлено/доставлено/прочитано)? A: Да, как минимум "доставлено" и "прочитано"

Q: Поддержка медиа-файлов (фото товара, документы)? A: Да, изображения обязательно для демонстрации товара

Q: Нужна ли история сообщений и как долго хранить? A: Да, минимум 1 год для разрешения споров

Q: Ограничения на размер сообщений? A: Текст до 1000 символов, изображения до 10MB

Q: Блокировка пользователей/спам-защита? A: Да, возможность заблокировать в чате + детекция спама

Q: Уведомления (push/email)? A: Push-уведомления обязательно, email опционально

Q: Групповые чаты с несколькими покупателями? A: Нет, только P2P

Нефункциональные требования

Производительность:

• Latency: <3 сек для доставки сообщений
• Throughput: поддержка пиковых нагрузок
• Concurrent users: до 500K одновременно

Масштабируемость:

• Пользователи: 50M зарегистрированных
• DAU: 5M активных пользователей в день
• Объявления: 100M активных объявлений

Надёжность:

• Availability: 99.9% (8.77 часов downtime/год)
• Durability: сообщения не должны теряться
• Backup: ежедневные бэкапы чатов

Безопасность:

• Authentication: интеграция с Avito auth
• Privacy: только участники чата видят сообщения
• Moderation: детекция спама и неприемлемого контента

Шаг 2: Расчёт нагрузки и объёма данных (8-10 минут)

Пользовательская активность

Базовые метрики:

- Зарегистрированных пользователей: 50M
- DAU (Daily Active Users): 5M  
- Активных объявлений: 100M
- Соотношение продавец/покупатель: 1:4

Активность в чатах:

- % пользователей, использующих чаты: 40% = 2M/день
- Новых чатов в день: 500K (10% от объявлений имеют активность)
- Сообщений на чат в среднем: 8 (2-3 обмена)
- Общих сообщений в день: 500K × 8 = 4M

Расчёт QPS (Queries Per Second)

Сообщения:

- Средний QPS: 4M / (24×3600) = 46 QPS
- Peak QPS: 46 × 10 = 460 QPS (вечерние часы)

API вызовы:

- Отправка сообщений: 460 QPS
- Получение истории чатов: 460 × 5 = 2,300 QPS  
- Список чатов пользователя: 2M / (24×3600) = 23 QPS
- Проверка новых сообщений: 2,300 QPS
- Обновление статусов: 460 × 2 = 920 QPS

Общий API QPS: ~6,200 QPS

Объём данных

Сообщения:

Структура сообщения:

- message_id: 8 байт
- chat_id: 8 байт  
- sender_id: 8 байт
- content: 200 символов × 2 = 400 байт (средний текст)
- created_at: 8 байт
- message_type: 1 байт
- status: 1 байт
- Итого: ~440 байт на сообщение

Ежедневный объём:

- 4M сообщений × 440 байт = 1.76GB/день
- За год: 1.76GB × 365 = 642GB
- За 3 года (с учётом роста): ~2TB

Чаты:

Структура чата:

- chat_id: 8 байт
- listing_id: 8 байт
- buyer_id: 8 байт
- seller_id: 8 байт
- created_at: 8 байт
- last_message_at: 8 байт
- status: 1 байт
- Итого: ~50 байт на чат

Объём чатов:

- 500K новых чатов/день × 50 байт = 25MB/день
- За год: 25MB × 365 = 9GB (незначительно)

Медиа-файлы:

Предположения:

- 30% сообщений содержат изображения
- Средний размер изображения: 2MB
- Сжатие и thumbnails: ×1.5 = 3MB на изображение

Объём медиа:

- 4M × 30% × 3MB = 3.6TB/день
- За год: 3.6TB × 365 = 1.3PB

Пропускная способность сети

Ingress (входящий):

- Текстовые сообщения: 460 QPS × 440 байт = 202KB/s
- Изображения: 138 QPS × 2MB = 276MB/s
- Общий ingress: ~280MB/s

Egress (исходящий):

- Доставка сообщений: 460 QPS × 440 байт × 2 = 404KB/s
- Отдача изображений: через CDN = 500MB/s
- История чатов: 2,300 QPS × 10KB = 23MB/s
- Общий egress: ~530MB/s

Шаг 3: Выбор типа взаимодействия (5 минут)

Анализ альтернатив для real-time коммуникации

1. HTTP Polling ❌

GET /api/chats/{chat_id}/messages/new каждые 5 секунд

Плюсы:

- Простота реализации
- Работает через любые proxy/firewall

Минусы:

- Высокая латентность (2.5 сек в среднем)
- Много пустых запросов (95%+ waste)
- Нагрузка на сервер: 2M пользователей × 0.2 QPS = 400K QPS
- НЕ соответствует требованию <3 сек

2. HTTP Long Polling ⚠️

GET /api/chats/{chat_id}/messages/wait (hold до 30 сек)

Плюсы:

- Низкая латентность (~100ms)
- Меньше waste запросов
- Fallback для старых браузеров

Минусы:

- Сложность управления connections
- Проблемы с proxy timeout
- Держит HTTP connections открытыми
- Сложность load balancing

3. Server-Sent Events (SSE) ⚠️

GET /api/chats/{chat_id}/events (EventSource)

Плюсы:

- Встроенная browser поддержка
- Automatic reconnection
- One-way от сервера к клиенту

Минусы:

- Только server→client (нужен отдельный API для отправки)
- Ограничения concurrent connections в браузере
- Проблемы с некоторыми proxy

4. WebSocket ✅ ВЫБОР

WS /api/chats/connect

Плюсы:

- Full-duplex communication
- Низкая латентность (<100ms)
- Эффективное использование bandwidth
- Нативная поддержка в браузерах
- Ideal для chat applications

Минусы:

- Сложность в поддержке (reconnection logic)
- Статeful connections (sticky sessions)
- Больше memory на сервере

ОБОСНОВАНИЕ: WebSocket optimal для chat с требованием <3 сек

Шаг 4: API Design (5 минут)

REST API + WebSocket

# === AUTHENTICATION ===
POST /api/v1/auth/token
{
  "avito_token": "...",
  "device_id": "mobile_123"
}

# === CHAT MANAGEMENT ===
# Создание чата (инициация из объявления)
POST /api/v1/chats
{
  "listing_id": 12345,
  "initial_message": "Здравствуйте, интересует ваш товар"
}
Response: {
  "chat_id": "550e8400-e29b-41d4-a716-446655440000",
  "listing_id": 12345,
  "participant_ids": [67890, 54321],
  "created_at": "2025-01-14T10:30:00Z"
}

# Получение списка чатов пользователя
GET /api/v1/chats?limit=20&offset=0
Response: {
  "chats": [
    {
      "chat_id": "550e8400-e29b-41d4-a716-446655440000",
      "listing_title": "iPhone 14 Pro",
      "participant_name": "Иван Петров",
      "last_message": "Когда можно посмотреть?",
      "last_message_at": "2025-01-14T15:20:00Z",
      "unread_count": 2,
      "chat_status": "active"
    }
  ],
  "total": 45
}

# === MESSAGE OPERATIONS ===
# Отправка сообщения (через WebSocket)
WS Message: {
  "action": "send_message",
  "chat_id": "550e8400-e29b-41d4-a716-446655440000",
  "content": "Добрый день! Товар ещё актуален?",
  "message_type": "text",
  "client_message_id": "client_123"
}

# Получение истории сообщений
GET /api/v1/chats/{chat_id}/messages?limit=50&before_message_id=abc123
Response: {
  "messages": [
    {
      "message_id": "msg_789",
      "sender_id": 67890,
      "content": "Добрый день! Товар ещё актуален?",
      "message_type": "text",
      "created_at": "2025-01-14T15:20:00Z",
      "status": "read",
      "read_at": "2025-01-14T15:21:00Z"
    }
  ]
}

# Пометка сообщений как прочитанных
POST /api/v1/chats/{chat_id}/mark_read
{
  "last_read_message_id": "msg_789"
}

# === MEDIA UPLOAD ===
POST /api/v1/media/upload
Content-Type: multipart/form-data
Response: {
  "media_id": "media_456",
  "url": "https://cdn.avito.ru/chat/images/media_456.jpg",
  "thumbnail_url": "https://cdn.avito.ru/chat/thumbs/media_456_thumb.jpg"
}

# === WEBSOCKET EVENTS ===
WS /api/v1/chats/connect?auth_token=jwt_token

# Входящие события:
{
  "event": "message_received",
  "chat_id": "550e8400-e29b-41d4-a716-446655440000", 
  "message": {
    "message_id": "msg_999",
    "sender_id": 54321,
    "content": "Да, товар доступен",
    "created_at": "2025-01-14T15:25:00Z"
  }
}

{
  "event": "message_status_updated",
  "message_id": "msg_789",
  "status": "read"
}

{
  "event": "typing_indicator",
  "chat_id": "550e8400-e29b-41d4-a716-446655440000",
  "user_id": 54321,
  "typing": true
}

Шаг 5: Database Schema (7 минут)

Выбор архитектуры: монолит vs микросервисы

Аргументация выбора микросервисов:

Почему микросервисы для Avito Messenger:

1. BUSINESS ALIGNMENT:

   - Chat Service независим от основного Avito
   - Разные команды могут развивать параллельно
   - Различные SLA требования

2. TECHNICAL BENEFITS:

   - Независимое масштабирование (chat vs listings)
   - Разные технологии (WebSocket servers vs CRUD APIs)
   - Изоляция отказов

3. AVITO CONTEXT:

   - Уже существует микросервисная архитектура
   - Интеграция с User Service, Listing Service
   - Потребуется интеграция с уведомлениями

Альтернатива (монолит):

- Проще в начале
- Меньше network overhead
- НО: не масштабируется для разных команд Avito

Микросервисная схема

1. Chat Service Database (PostgreSQL)

-- Чаты
CREATE TABLE chats (
    chat_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    listing_id BIGINT NOT NULL,
    buyer_id BIGINT NOT NULL,
    seller_id BIGINT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    last_message_at TIMESTAMP,
    last_message_id UUID,
    chat_status VARCHAR(20) DEFAULT 'active', -- active, blocked, archived
    buyer_unread_count INT DEFAULT 0,
    seller_unread_count INT DEFAULT 0
);

-- Индексы для списка чатов пользователя  
CREATE INDEX idx_chats_buyer ON chats(buyer_id, last_message_at DESC);
CREATE INDEX idx_chats_seller ON chats(seller_id, last_message_at DESC);
CREATE INDEX idx_chats_listing ON chats(listing_id);

-- Составной индекс для уникальности чата
CREATE UNIQUE INDEX idx_chats_unique ON chats(listing_id, buyer_id, seller_id);

2. Message Service Database (Cassandra - обоснование выбора)

Почему Cassandra для сообщений:

1. WRITE HEAVY: 460 QPS записи, высокая write throughput
2. TIME-SERIES: сообщения append-only с timestamp ordering  
3. PARTITION TOLERANCE: автоматический sharding
4. SCALABILITY: linear scaling при добавлении узлов

Альтернативы:

- PostgreSQL: ограниченная write scalability
- MongoDB: хорошо, но Cassandra лучше для time-series

-- Cassandra schema
CREATE TABLE messages (
    chat_id UUID,
    message_id UUID,
    created_at TIMESTAMP,
    sender_id BIGINT,
    content TEXT,
    message_type VARCHAR(20), -- text, image, document
    media_url TEXT,
    status VARCHAR(20), -- sent, delivered, read
    read_at TIMESTAMP,
    PRIMARY KEY (chat_id, created_at, message_id)
) WITH CLUSTERING ORDER BY (created_at DESC, message_id ASC);

-- Таблица для поиска сообщений по ID
CREATE TABLE messages_by_id (
    message_id UUID PRIMARY KEY,
    chat_id UUID,
    created_at TIMESTAMP,
    sender_id BIGINT,
    content TEXT,
    message_type VARCHAR(20),
    media_url TEXT,
    status VARCHAR(20),
    read_at TIMESTAMP
);

3. User Service Database (существующий Avito)

-- Подключаемся к существующему User Service
-- Получаем данные через API calls

-- Кеширование в Chat Service
CREATE TABLE user_cache (
    user_id BIGINT PRIMARY KEY,
    username VARCHAR(100),
    avatar_url VARCHAR(500),
    cached_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

4. Connection Service Database (Redis)

# Активные WebSocket соединения
user_connections:{user_id} = {
  "server_id": "chat-server-3",
  "socket_id": "ws_12345",
  "connected_at": "2025-01-14T10:30:00Z"
}
TTL: 300 seconds (heartbeat)

# Typing indicators
typing:{chat_id} = {
  "user_id": 67890,
  "expires_at": 1705234200
}
TTL: 10 seconds

# Message delivery queue для offline пользователей
offline_messages:{user_id} = [
  {
    "chat_id": "550e8400-e29b-41d4-a716-446655440000",
    "message_id": "msg_123",
    "created_at": "2025-01-14T10:30:00Z"
  }
]
TTL: 30 days

Ключи шардирования

Chat Service (PostgreSQL):

-- Шардинг по user_id для списка чатов
-- Проблема: как получить чаты где пользователь = buyer ИЛИ seller?

-- Решение: денормализация
CREATE TABLE user_chats (
    user_id BIGINT,
    chat_id UUID,
    role VARCHAR(10), -- buyer, seller
    listing_id BIGINT,
    other_user_id BIGINT,
    last_message_at TIMESTAMP,
    unread_count INT DEFAULT 0,
    PRIMARY KEY (user_id, last_message_at DESC, chat_id)
);

-- Шардинг: user_id % 16 = shard_number
-- Один запрос получает все чаты пользователя

Message Service (Cassandra):

Ключ партиционирования: chat_id
Clustering key: created_at DESC, message_id

Преимущества:

- Все сообщения чата на одном узле
- Эффективные range queries по времени
- Автоматическое распределение по chat_id

Недостатки:

- Hot partition если один чат очень активный
- Но для P2P чатов это маловероятно

Шаг 6: Архитектура системы (10 минут)

Высокоуровневая архитектура

                        [Internet/Mobile Apps]
                                 |
                          [Load Balancer L7]
                                 |
                        [API Gateway (Kong)]
                                 |
          ┌─────────────────────┼─────────────────────┐
          |                     |                     |
   [Chat Service]    [Message Service]    [Media Service]
          |                     |                     |
   [PostgreSQL]           [Cassandra]            [S3 + CDN]
          |                     |
          └─────────────────────┼─────────────────────┘
                                |
                    [Redis Cluster (Connection/Cache)]
                                |
                    [Message Queue (Kafka)]
                                |
                    [Notification Service]

Детальная архитектура компонентов

1. API Gateway (Kong/Zuul)

Функции:

- Authentication (JWT validation)
- Rate limiting (10 сообщений/минуту на пользователя)
- Request routing к микросервисам  
- Request/response logging
- API versioning

Конфигурация rate limiting:

- Chat API: 100 requests/minute per user
- Message send: 10 messages/minute per user  
- Media upload: 5 uploads/minute per user

2. Chat Service (Node.js/Go)

Ответственность:

- WebSocket connection management
- Real-time message routing
- Chat creation/management
- Integration с Listing Service для проверки объявлений

WebSocket Management:

- Sticky sessions через Load Balancer
- Connection registry в Redis
- Heartbeat monitoring (30 сек)
- Graceful reconnection logic

Scaling: 5 инстансов × 10K connections = 50K concurrent

3. Message Service (Java/Scala)

Ответственность:

- Message persistence в Cassandra
- Message status updates (delivered/read)
- Message history API
- Integration с модерацией

Асинхронная обработка:

- Message Queue (Kafka) для decoupling
- Batch processing для статистики
- Dead letter queue для failed messages

4. Media Service (Go/Python)

Ответственность:

- Image upload/processing
- Thumbnail generation
- CDN integration
- Content moderation (AI для неприемлемого контента)

Processing pipeline:

- Upload → S3 staging
- Resize/optimize → multiple formats
- Upload → S3 production + CDN
- Virus scanning

Балансировка нагрузки

Load Balancer выбор и обоснование:

L4 vs L7 выбор для WebSocket:

L4 (Transport Layer):
+ Высокая производительность
+ Поддержка sticky sessions по IP
- Нет application-level routing
- Сложнее debugging

L7 (Application Layer):  ✅ ВЫБОР
+ WebSocket-aware routing
+ Health checks на application level
+ Routing по headers (user_id)
+ Better observability
- Немного больше latency

Алгоритм: Consistent Hashing по user_id
Причина: WebSocket требует sticky sessions

Конфигурация HAProxy:

# WebSocket routing
backend chat_servers
    balance source
    hash-type consistent
    stick-table type string len 32 size 100k expire 30m
    stick on hdr(X-User-ID)
    
    server chat1 10.0.1.10:8080 check
    server chat2 10.0.1.11:8080 check  
    server chat3 10.0.1.12:8080 check

Асинхронное взаимодействие (Kafka)

Message Topics:

1. chat.messages.created
   - Новые сообщения для persistence
   - Consumers: Message Service, Analytics
   
2. chat.messages.status_updated  
   - Обновления статусов (delivered/read)
   - Consumers: Message Service, Push Service
   
3. chat.moderation.required
   - Сообщения требующие модерации
   - Consumers: Moderation Service
   
4. chat.analytics.events
   - События для аналитики
   - Consumers: Analytics Service

Partitioning: по chat_id для ordering гарантий
Replication: 3 replicas для durability

Message Flow через Kafka:

1. User A отправляет сообщение через WebSocket
2. Chat Service валидирует и публикует в Kafka
3. Chat Service отправляет ACK пользователю A (status: sent)
4. Message Consumer читает из Kafka → сохраняет в Cassandra
5. Если User B online → Chat Service доставляет через WebSocket
6. Если User B offline → сохраняет в Redis queue
7. User B читает → публикует status update в Kafka

Шаг 7: Надёжность и масштабируемость (8 минут)

Обеспечение SLA 99.9%

1. Database Reliability

PostgreSQL (Chat Service):

- Primary-Secondary setup (streaming replication)
- Automatic failover с Patroni
- Connection pooling (PgBouncer): 100 connections per server
- Read replicas для read-heavy операций (список чатов)

Cassandra (Message Service):  

- 3 узла кластер, RF=3
- Multi-datacenter для disaster recovery
- Automatic repair processes
- Monitoring с Nodetool

2. Service Reliability

Circuit Breaker pattern:

- Message Service → Chat Service calls
- Chat Service → User Service calls  
- Timeout: 5 секунд
- Failure threshold: 5 errors in 1 minute
- Half-open retry: after 30 seconds

Retry logic:

- Message delivery: exponential backoff (1s, 2s, 4s, 8s)
- API calls: 3 retries with jitter
- Kafka produce: infinite retries with backoff

3. Graceful Degradation

Сценарии деградации:
1. Cassandra недоступна:

   - Сообщения в Kafka queue (retention 7 дней)
   - Read-only mode для истории
   - WebSocket продолжает работать

2. Redis недоступен:

   - WebSocket connections в memory
   - Отключение typing indicators
   - Offline messages в PostgreSQL

3. Media Service недоступен:

   - Только текстовые сообщения
   - Отложенная обработка медиа

Масштабирование

Horizontal Scaling Strategy:

Chat Service:

- Auto-scaling по CPU (target: 70%)
- Min: 3 instances, Max: 20 instances
- Rolling deployment без downtime
- Connection draining при scale-down

Message Service:  

- Stateless сервис, легко масштабируется
- Auto-scaling по Kafka consumer lag
- Min: 2 instances, Max: 10 instances

Cassandra:

- Добавление узлов без downtime
- Rebalancing данных автоматически
- Monitoring memory и CPU per node

Sharding Evolution:

Текущий план (до 10M пользователей):

- PostgreSQL: 4 шарда по user_id
- Cassandra: 3 узла, автоматическое распределение

Future (10M+ пользователей):

- PostgreSQL: 16 шардов
- Cassandra: 9 узлов (3 per datacenter)
- Read replicas по географиям

Monitoring и Alerting

Business Metrics (KPI):

1. Message Delivery Success Rate
   - Target: >99.5%
   - Alert: <99% за 5 минут
   
2. Message Delivery Latency
   - Target: p95 < 2 секунды
   - Alert: p95 > 5 секунд за 2 минуты
   
3. WebSocket Connection Success Rate
   - Target: >99%
   - Alert: <98% за 1 минуту
   
4. Chat Creation Success Rate
   - Target: >99.9%
   - Alert: <99% за 1 минуту

5. Daily Active Chats
   - Track: growth/decline trends
   - Alert: >20% drop day-over-day

Technical Metrics:

Application Level:

- API response time (p50, p95, p99)
- Error rate по endpoints
- WebSocket connection count
- Kafka consumer lag
- Memory/CPU utilization per service

Database Level:

- PostgreSQL: connection pool usage, query time, replication lag
- Cassandra: read/write latency, compaction pending, disk usage  
- Redis: memory usage, key expiration rate, connection count

Infrastructure Level:

- Network latency между сервисами
- Disk I/O на database nodes
- Load balancer connection errors
- CDN cache hit ratio для медиа

Alerting Rules:

Critical (PagerDuty):

- Message delivery failure >1% за 2 минуты
- WebSocket connection drops >10% за 1 минуту  
- Database primary down
- Kafka cluster unavailable

Warning (Slack):

- API latency p95 >3 секунды за 5 минут
- Database connection pool >80%
- Disk usage >85%
- Error rate >0.5% за 10 минут

Info (Dashboard):

- Daily/hourly traffic patterns
- User engagement metrics
- Storage growth trends

Шаг 8: Security и Moderation (3 минуты)

Authentication & Authorization

JWT Token Integration:

- Использование существующего Avito auth
- Token содержит: user_id, permissions, exp
- Refresh logic для long-lived connections

WebSocket Authentication:

- JWT в query parameter при подключении
- Periodic token refresh через ping/pong
- Automatic disconnect при expired token

Spam Protection & Moderation

Rate Limiting (по приоритету):
1. Message sending: 10 сообщений/минуту
2. Chat creation: 5 чатов/час  
3. Media upload: 3 файла/час

Content Moderation:

- Real-time keyword filtering
- ML-based spam detection (TensorFlow Serving)
- Image content analysis для неприемлемого контента
- Manual review queue для edge cases

Auto-blocking Rules:

- Identical messages >3 раза → temporary block
- Reported by >3 пользователя → auto-review
- External links → require approval

Шаг 9: Рассмотрение альтернатив (3 минуты)

Database Alternatives

Вместо Cassandra для сообщений:

MongoDB:
+ Более привычный для команды
+ Лучшие query возможности
+ Transactions support
- Меньше write throughput чем Cassandra
- Сложнее horizontal scaling

PostgreSQL + Partitioning:
+ Знакомая технология
+ ACID transactions
+ Rich query capabilities
- Write bottleneck при scale
- Сложнее sharding логика

DynamoDB:
+ Managed service (меньше ops)
+ Auto-scaling
+ Predictable performance
- Vendor lock-in
- Дороже при высокой нагрузке
- Сложнее complex queries

ВЫБОР Cassandra: оптимальна для append-only сообщений с high write load

Architecture Alternatives

Event Sourcing + CQRS:

Альтернативный подход:

- Event Store для всех chat events
- Separate read models для queries
- Perfect audit trail

Плюсы:
+ Полная история событий
+ Легко добавлять новые projections
+ Natural event-driven architecture

Минусы:

- Complexity overhead для simple chat
- Eventual consistency challenges
- Learning curve для команды

РЕШЕНИЕ: Не подходит для MVP, рассмотреть при scale >10M пользователей

Serverless Architecture:

AWS Lambda + API Gateway:
+ Auto-scaling
+ Pay per request
+ Zero server management

Минусы:

- Cold start latency (не подходит для <3 сек requirement)
- WebSocket limitations в Lambda
- Vendor lock-in
- Сложность debugging

РЕШЕНИЕ: Не подходит для real-time WebSocket requirements

Message Queue Alternatives

Redis Streams вместо Kafka:

Redis Streams:
+ Проще setup и management  
+ Lower latency
+ Integrated с Redis cache

Минусы:

- Меньше throughput чем Kafka
- Нет built-in partitioning
- Single point of failure

RabbitMQ:
+ Feature-rich messaging
+ Dead letter queues
+ Management UI

Минусы:  

- Сложнее scaling
- Меньше throughput

ВЫБОР Kafka: лучше для high-throughput и уже используется в Avito

Шаг 10: План развертывания и миграции (2 минуты)

Phase 1: MVP (месяцы 1-2)

Цель: Базовый функционал для тестирования

Компоненты:

- Chat Service (простой WebSocket server)  
- Message API (REST только)
- PostgreSQL для всех данных
- Redis для WebSocket connections
- Базовый UI integration

Ограничения:

- Только текстовые сообщения
- Без real-time (polling каждые 5 сек)
- Single datacenter
- Manual deployment

Phase 2: Production Ready (месяцы 3-4)

Добавления:

- WebSocket real-time messaging
- Cassandra для message storage
- Kafka для async processing
- Media upload support
- Load balancing + auto-scaling
- Monitoring и alerting
- CI/CD pipeline

Phase 3: Scale & Features (месяцы 5-6)

Оптимизации:

- Multi-region deployment
- Advanced moderation
- Push notifications
- Analytics dashboard
- Performance optimizations
- Disaster recovery procedures

Миграция существующих данных:

Если есть существующая система:

1. Dual-write period:

   - Новые сообщения в обе системы
   - Read from old system
   - Data consistency validation

2. Backfill historical data:

   - Batch migration в off-peak hours
   - Chat metadata migration
   - Message history migration
   - Media files migration

3. Cutover:

   - Feature flag для переключения reads
   - Monitoring для validation
   - Rollback plan готов

Заключение: Финальная архитектура

Выбранная архитектура

                    [CDN (CloudFlare)]
                           |
                    [Load Balancer L7]
                           |
                   [API Gateway (Kong)]
                           |
        ┌─────────────────┼─────────────────┐
        |                 |                 |
   [Chat Service]  [Message Service]  [Media Service]
   WebSocket+REST     REST+Kafka        Upload+CDN
        |                 |                 |
   [PostgreSQL]      [Cassandra]          [S3]
   4 shards          3-node cluster    Multi-region
        |                 |                 |
        └─────────────────┼─────────────────┘
                          |
                   [Redis Cluster]
                   Connection mgmt
                          |
                   [Kafka Cluster]
                   Async messaging
                          |
                 [Notification Service]
                   Push notifications

Ключевые решения с обоснованием:

1. WebSocket для real-time: единственный способ достичь <3 сек latency
2. Микросервисы: независимое развитие и масштабирование компонентов
3. Cassandra для сообщений: оптимальна для write-heavy, time-series данных
4. PostgreSQL для чатов: ACID для metadata, привычная технология
5. Kafka для async: надёжная доставка и декаплинг сервисов
6. Sharding по user_id: эффективные queries для списка чатов пользователя

Соответствие требованиям:

• ✅ Latency <3 сек: WebSocket обеспечивает ~100ms
• ✅ 6,200 QPS: архитектура поддерживает с запасом
• ✅ 99.9% availability: redundancy на всех уровнях
• ✅ Интеграция с объявлениями: через Listing Service API
• ✅ P2P чаты: простая модель данных
• ✅ Список чатов: эффективный sharding по user_id

Метрики успеха:

• Business: 40% пользователей используют чаты, конверсия объявление→сделка +15%
• Technical: p95 latency <2 сек, 99.5% delivery rate, 99.9% uptime
• User Experience: <100ms typing indicators, instant read receipts

Эта архитектура обеспечивает надёжную основу для Messenger Avito с возможностью масштабирования до 50M пользователей и легкой интеграции с существующей экосистемой Avito.