Архитектура highload-систем: опыт AXIIOM

Highload — это не только про миллионы пользователей. Это про предсказуемость, отказоустойчивость и стоимость ошибки. Когда ваша система обрабатывает 1000+ запросов в секунду (RPS), каждая непродуманная деталь превращается в инцидент.

В этой статье команда AXIIOM делится практическим опытом: что работает, а что нет, как выбирать между монолитом и микросервисами, строить кэширование, балансировку и оркестрацию. И главное — как не наломать дров на старте.

Highload — это не про технологии, а про подход

Highload начинается с архитектурных принципов: масштабируемость (способность расти горизонтально без переписывания кода); отказоустойчивость (выход одного сервера не должен ронять всю систему); наблюдаемость (метрики, логи и трейсы каждой транзакции); асинхронность (очереди и события вместо блокировок).

Микросервисы vs Монолит: когда что выбирать

Начинать лучше с хорошо структурированного монолита, а микросервисы вводить по мере необходимости. Монолит — простой деплой, лучшая производительность на низкой нагрузке, ACID-транзакции. Подходит для команды до 10 разработчиков и нагрузки до 1000 RPS. Микросервисы — независимое масштабирование, слабые связи, но выше DevOps-нагрузка. Оправданы от 1000 RPS и команде от 20 человек.

Компромисс: модульный монолит с чёткими доменными границами. При росте нагрузки горячие модули выносятся в отдельные сервисы постепенно.

Балансировка нагрузки: уровни и алгоритмы

Используем L7-балансировку (nginx, HAProxy) — она даёт гибкость по заголовкам, cookies, URL-роутингу. Health Check: балансировщик стучится в /health каждого бэкенда. Circuit Breaker (Hystrix, Resilience4j): при превышении порога ошибок клиент перестаёт слать запросы и возвращает fallback.

Пример из AXIIOM: в платёжной системе с пиками 3000 RPS circuit breaker для сервиса банка-эквайера переключал трафик на резервного при проблемах. Процент отказов упал с 5% до 0.3%.

Алгоритмы: Round Robin (простой), Least Connections (для длительных запросов), Random (для stateless бэкендов).

Кэширование: многоуровневая стратегия

Уровни: CDN (статику, 1-24ч), HTTP-кэш Nginx (страницы для неавторизованных, 1-60мин), локальный кэш приложения (повторяющиеся запросы, 5-30сек), Redis (сессии и частые объекты, 30сек-1ч), БД-кэш (InnoDB buffer pool).

Правила: кэшируй как можно выше (ближе к клиенту); не кэшируй персонализированный контент; для Redis используй maxmemory-policy allkeys-lru и кластеризацию. Cache stampede — решается через SETNX или случайное TTL.

Кейс AXIIOM: для онлайн-кинотеатра с 2 млн DAU настроили многоуровневое кэширование: CDN (постеры), Redis (описания, рейтинги), локальный кэш в API. 98% запросов к каталогу из кэша, нагрузка на базу упала на 90%.

Горизонтальное масштабирование: Kubernetes

Kubernetes — стандарт для highload: HPA (Horizontal Pod Autoscaler) по CPU, памяти или кастомным метрикам; самовосстановление; декларативность.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payments-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payments
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Что важно: stateless приложения, graceful shutdown, readiness и liveness probe. Когда K8s избыточен: меньше 5 микросервисов и нагрузки <100 RPS.

Работа с базами данных: шардирование и репликация

Три паттерна: Master-Replica (чтение/запись, read-heavy), шардирование по ключу (горизонтальное), NewSQL (CockroachDB, TiDB). Начинаем с PostgreSQL + реплики чтения. Когда реплики перестают справляться — шардирование на уровне приложения.

Кейс: для B2B платформы с 2000 записей/сек шардировали таблицу счетов на 64 шарда PostgreSQL с consistent hashing.

Асинхронность и очереди

Синхронные вызовы убивают highload. Очереди нужны для: обработки изображений, рассылок, логирования, компенсационных транзакций. Выбор: Redis Streams (простые задачи), Kafka (высокая нагрузка, хранение событий), RabbitMQ (worker-очереди).

Наблюдаемость (Observability)

Три столпа: метрики (Prometheus + Grafana) — CPU, память, RPS, latency p50/p95/p99; логи (ELK или Loki) — ошибки и события; трейсинг (Jaeger, Zipkin) — распределённая трассировка. Внедряйте с первого дня.

Частые ошибки в highload-проектах

Ранняя оптимизация (микросервисы до 100 пользователей); игнорирование backpressure (OOM и падение системы); отсутствие нагрузочного тестирования до релиза; единая БД для аналитики и транзакций; необратимые миграции без плана отката.

Как мы в AXIIOM проектируем highload

Анализ нагрузочных профилей (пиковые RPS, чтение/запись); выбор архитектурного стиля (модульный монолит для MVP); прототипирование узких мест (схема БД, кэширование); нагрузочные тесты (K6, JMeter) до написания основного кода; CI/CD с автотестами производительности; пост-релизный мониторинг.

Пример из портфолио: платёжный шлюз для агрегатора такси с пиком 15 000 RPS. API на Go в K8s, Redis Cluster (10 нод), Kafka + ClickHouse для аналитики, nginx L7 с circuit breaker. Результат: p99 latency 47 мс, два года без сбоев.

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

Highload — это подход, а не технология. Начинайте с монолита, проектируйте модульно. Измеряйте всё. Балансировка и отказоустойчивость — с первого дня. Кэшируйте многоуровнево. Тестируйте нагрузкой до релиза.

AXIIOM — надёжные highload-решения, которые масштабируются с вашим бизнесом.