Аннотация. Данный курс посвящен проектированию, разработке и эксплуатации высоконагруженных систем (Highload Systems). В современном мире миллионы пользователей ежедневно взаимодействуют с онлайн-сервисами, социальными сетями, платежными системами и стриминговыми платформами. Эти системы должны работать без сбоев, обрабатывать терабайты данных и отвечать на запросы за миллисекунды. Курс решает ключевую проблему: как спроектировать архитектуру, которая не “упадет” под лавинообразным ростом нагрузки, оставаясь при этом отказоустойчивой, масштабируемой и экономически эффективной. Целевая аудитория — инженеры, которые хотят перейти от работы над “пет-проектами” к созданию систем уровня Google, Amazon или ВКонтакте.

Цель: После прохождения курса вы сможете самостоятельно спроектировать, реализовать и обосновать архитектуру высоконагруженной системы, способной обслуживать более миллиона одновременных пользователей с временем ответа менее 100 миллисекунд.

Для кого этот курс.

Будет полезно: разработчикам backend (Java, Go, C++, Python), системным архитекторам, DevOps-инженерам и техническим лидерам (Tech Lead), которые уже сталкивались с падением прод-сервиса из-за возросшего трафика и хотят системно подойти к решению проблем масштабирования. Курс ориентирован на специалистов с опытом работы от 3 лет, знакомых с основами сетей, многопоточностью и реляционными базами данных.

НЕ подойдёт: начинающим разработчикам без понимания основ HTTP, баз данных и Linux, а также тем, кто ищет “волшебную кнопку” для мгновенного ускорения приложения без изменения архитектуры — здесь придётся много и глубоко работать.

Теорема CAP: выбор между согласованностью, доступностью и устойчивостью к разделению. Теорема CAP (Consistency, Availability, Partition Tolerance) — это краеугольный камень проектирования распределенных систем. Она утверждает, что в любой системе, обменивающейся данными через сеть (которая всегда ненадежна), невозможно одновременно обеспечить: абсолютную согласованность данных (каждая реплика видит одну и ту же версию данных), абсолютную доступность (каждый запрос получает ненулевой ответ, пусть даже устаревший) и устойчивость к разделению на изолированные группы (система продолжает работать, даже если связь между узлами прервана). На практике архитектор всегда выбирает AP (доступность и устойчивость к разделению, жертвуя строгой согласованностью) или CP (согласованность и устойчивость к разделению, жертвуя доступностью некоторых узлов). Классический пример: Cassandra — это AP-система, а HBase — CP-система. При проектировании highload architect обязан осознанно сделать этот выбор на основе предметной области: для системы бронирования билетов (CP) критична согласованность, а для ленты новостей соцсети (AP) — доступность.

Теорема PACELC: расширенная модель для баз данных. Если теорема CAP описывает поведение системы во время сетевого разделения (P — Partition), то модель PACELC уточняет выбор в нормальном режиме работы (E — Else). Полная аббревиатура расшифровывается как: Partition (разделение) -> выбор между Availability и Consistency; Else (нет разделения) -> выбор между Latency (задержкой) и Consistency. Многие NoSQL базы данных, такие как DynamoDB или Cassandra, в обычном режиме выбирают низкую задержку (L), позволяя читать слегка устаревшие данные (eventual consistency), что дает выигрыш в производительности. В то же время реляционные базы данных в кластере часто жертвуют задержкой ради строгой согласованности. Понимание PACELC позволяет highload architect точно предсказать поведение хранилища данных под нагрузкой: для OLTP-систем с высокой частотой записи важен выбор (L) для снижения конкуренции, а для финансового аудита — строгая согласованность даже ценой дополнительных миллисекунд.

Модели согласованности данных: от строгой до финальной. Согласованность — это контракт между системой и разработчиком о том, когда и в каком порядке операции записи становятся видны для последующих чтений. В highload architect используются следующие уровни: Строгая согласованность (linearizability) — чтение всегда возвращает результат последней записи, как будто система одна, но это очень дорого и замедляет распределенные операции. Последовательная согласованность (sequential consistency) — операции всех потоков видны в одном глобальном порядке, но порядок может не совпадать с реальным временем. Кausalльная согласованность — сохраняет порядок только причинно-связанных операций (если A вызвало B, то все увидят A раньше B), но независимые операции могут перемешиваться. И наконец, Eventual (финальная) согласованность — если на систему не поступают новые записи, то через некоторое время все реплики сойдутся к одному значению. Этот тип используется в DNS, Amazon S3 и многих социальных сетях, где цена абсолютной свежести данных неоправданно высока.

Алгоритм консенсуса Raft: подробный разбор работы. Алгоритм Raft был создан как более понятная альтернатива сложному Paxos для решения задачи консенсуса — согласования единого значения между несколькими узлами в условиях отказов. Он работает на основе трех ключевых компонентов: выборы лидера, репликация журнала и безопасность. В любой момент каждый узел находится в одном из состояний: follower , candidate или leader . Изначально все узлы — последователи (followers). Если follower не получает heartbeat от лидера за определенный таймаут, он становится кандидатом (candidate), увеличивает свой термин (term) и голосует сам за себя, после чего запрашивает голоса у других. Победителем становится кандидат, получивший >N/2 голосов. Лидер принимает все клиентские запросы, добавляет их как новые записи в свой журнал (log entry) и рассылает команду AppendEntries последователям. Запись считается зафиксированной (committed), когда лидер получил подтверждение от большинства (>N/2) последователей, после чего применяется к состоящему автомату (state machine). Даже если лидер падает, новый лидер гарантирует, что зафиксированные записи никогда не будут перезаписаны. Raft используется в таких системах, как etcd (хранилище метаданных Kubernetes), Consul и TiDB.

Сравнение Raft и Paxos: когда что выбирать. Paxos, изобретенный Лесли Лэмпортом, был первым практически применимым алгоритмом консенсуса, но его понимание и имплементация крайне сложны из-за асимметрии ролей и многоэтапных протоколов. Классический Paxos включает фазы Prepare, Promise, Accept и Learn, при этом обработка “шумных” лидеров (dueling proposers) может привести к livelock. Raft же, напротив, был разработан с принципом “understandability first” и сводит консенсус к проблеме избрания сильного лидера, после чего вся репликация идет через него линейно. Для большинства прикладных задач в highload architect, таких как распределенные блокировки, кластерные очереди или сервис конфигураций, Raft — предпочтительный выбор из-за простоты отладки и богатой экосистемы (готовые библиотеки на Go, Java, Rust). Paxos же находит применение в очень высокопроизводительных системах с минимальным оверхедом, где каждый такт на счету (например, в некоторых WAN-репликациях баз данных), но его реализацию лучше делегировать проверенным продуктам, а не писать с нуля.

Вертикальное масштабирование (scale-up) и его пределы. Вертикальное масштабирование — это самый простой, но быстро достигающий предела способ увеличить производительность: вы просто покупаете более мощный сервер с большим количеством ядер, оперативной памяти (например, 2-8 ТБ) или заменяете HDD на сверхбыстрые NVMe SSD. Плюсы: не нужно менять архитектуру приложения, проще администрировать (один сервер), нет проблем с распределенными транзакциями. Минусы, которые делают его непригодным для highload architect: существует физический предел мощности процессора и объема памяти для одной машины (суперкомпьютеры — исключение, но они стоят миллионы), стоимость растет нелинейно (сервер в 10 раз мощнее стоит в 30-50 раз дороже), и главное — вы получаете единую точку отказа (SPOF). Если вертикально масштабируемый сервер упадет, система ляжет полностью. Поэтому scale-up используется лишь на начальных этапах стартапа или для некритичных компонентов с предсказуемой нагрузкой, но не как основная стратегия роста.

Горизонтальное масштабирование (scale-out) и шардирование. Горизонтальное масштабирование — это добавление большого количества стандартных (товарных) серверов в кластер, где каждый обрабатывает только часть данных или запросов. Именно этот подход лежит в основе современных облачных систем (AWS, GCP) и больших данных. Ключевой паттерн здесь — шардирование (sharding). Шард — это горизонтальное разделение данных: таблица базы данных разбивается на независимые части по правилу, называемому shard key. Например, пользователи с user_id от 1 до 1 миллиона попадают в шард на сервере A, а с 1 миллиона до 2 миллионов — на сервере B. Самый простой, но опасный подход — модульное шардирование (hash(key) % N). При добавлении нового сервера (N+1) почти все данные перераспределяются, вызывая лавину миграций. Поэтому профессионалы используют consistent hashing (кольцевой хеш), который при добавлении узла требует перемещения только K/N данных, где K — ключей, а N — узлов. Highload architect должен также помнить о проблеме “горячих шардов” (hot shard), когда один раздел получает непропорционально много запросов (например, пользователи-блогеры с миллионами подписчиков) — здесь помогают dynamic sharding или выделенные маршрутизаторы.

Репликация данных: master-slave, master-master и quorum-based подходы. Репликация предназначена для обеспечения отказоустойчивости (redundancy) и масштабирования чтения. В схеме master-slave (leader-follower) есть один главный узел, принимающий все записи, и несколько подчиненных узлов, асинхронно повторяющих эти изменения. Чтение можно распределять между репликами. Проблема: при падении мастера запись становится недоступной до выборов нового лидера, а также возможна потеря данных (если реплика не успела принять изменения). Master-master (multi-leader) — два или более мастеров одновременно пишут данные, что увеличивает пропускную способность записи, но требует разрешения конфликтов (например, через vector clocks или last-write-wins). Самый надежный, но сложный метод — quorum-based репликация, используемая в Cassandra и DynamoDB. Здесь настройка R (количество успешных чтений) и W (количество успешных записей) задается архитектором. Если всего N реплик, то правила: W + R > N гарантируют строгую согласованность (если W > N/2 и R > N/2). Стандарт для highload: часто выбирают N=3, W=2, R=2 — баланс между доступностью и консистентностью, при котором система переживет потерю одного узла.

Балансировка нагрузки: стратегии и алгоритмы (Round Robin, Least Connections, Consistent Hashing). Балансировщик нагрузки (load balancer) — это диспетчер трафика, распределяющий запросы между пулом серверов. Round Robin (RR) — простейший алгоритм, отправляющий запросы по кругу (1-2-3-1-2-3...), но он не учитывает разную мощность серверов или время обработки запроса. Weighted RR добавляет веса: сервер с 8 vCPU получает в 2 раза больше трафика, чем сервер с 4 vCPU. Least Connections (LC) — алгоритм, динамически отправляющий запрос тому серверу, у которого сейчас меньше всего активных соединений; эффективен для запросов с сильно варьирующимся временем выполнения (например, загрузка видео). Consistent Hashing — идеальный выбор для кэшей или шардированных БД: он гарантирует, что запросы с одним ключом всегда попадают на один и тот же бэкенд (пока сервер в кольце), а при добавлении нового сервера минимизирует перераспределение ключей. На практике highload architect комбинирует эти методы: на внешнем контуре (L4/TCP) используется ECMP или HAProxy с leastconn, на внутреннем (L7/HTTP) — NGINX или Envoy с consistent hashing на основе X-User-ID.

Автомасштабирование (Auto-scaling): метрики, политики и cooldown. Автомасштабирование позволяет кластеру динамически менять количество работающих экземпляров (подов в Kubernetes, EC2-инстансов в AWS Auto Scaling Groups) в зависимости от реальной нагрузки. Ключевые метрики: CPU Utilization (целевое значение 60-70%), Memory Usage (опасно выше 90%, иначе OOM killer), Requests per Second (RPS) на инстанс, а также Queue Length в брокерах сообщений. Политики масштабирования бывают: target tracking policy (просто поддерживаем метрику на уровне 60%), step scaling (добавить 2 инстанса, если CPU > 80% на 5 минут) и scheduled scaling (на каждый пятничный вечер увеличиваем парк серверов на 30%). Критически важный параметр — cooldown period (5-15 минут), который запрещает повторное масштабирование сразу после предыдущего, чтобы избежать “раскачки” (thrashing), когда система постоянно добавляет и удаляет серверы каждые пару минут. В highload architect обязательно настраивают scale-out (добавление) более агрессивно, чем scale-in (удаление), чтобы падение нагрузки не приводило к преждевременному высвобождению мощностей.

Декомпозиция предметной области для социальной сети. При разработке социальной сети первым шагом архитектора является функциональная декомпозиция — разделение системы на слабо связанные домены (bounded contexts) по методологии Domain-Driven Design (DDD). Каждый домен будет обслуживаться отдельным микросервисом или группой сервисов. Выделяем следующие контексты: User Profile (регистрация, авторизация, просмотр анкет), Social Graph (друзья, подписчики, блокировки), Feed & Timeline (генерация новостной ленты), Messaging (личные сообщения), Content Storage (фото, видео, посты), Notifications (пуш-уведомления, емейлы). Также необходим API Gateway как единая точка входа для клиентов (мобильные приложения, веб, API для сторонних разработчиков), который будет заниматься маршрутизацией, аутентификацией, лимитированием запросов (rate limiting) и агрегацией ответов от внутренних сервисов. Такая декомпозиция позволяет командам разрабатывать сервисы независимо, масштабировать только горячие домены (например, Feed зимой в период повышенной активности) и изолировать отказы.

Проектирование базы данных пользователей под миллиард записей. Таблица пользователей — это сердце социальной сети, и при росте до миллиарда строк традиционные реляционные БД с монолитной структурой становятся узким местом. Архитектор выбирает стратегию шардирования по user_id с использованием алгоритма consistent hashing. Количество физических шардов фиксируется заранее с большим запасом (например, 4096 логических шардов), которые размещаются на меньшем количестве физических серверов БД (например, 16 серверов PostgreSQL или Cassandra). Каждый сервер будет отвечать за диапазон ключей (например, шарды 0-255, 256-511 и т.д.). Для операций, которые требуют полного сканирования (админка, сбор аналитики), используется secondary index, который строится отдельно в Elasticsearch или ClickHouse. Поля пользователя делятся на горячие (часто обновляемые: статус, последний визит, аватар) и холодные (редко меняющиеся: дата регистрации, город, образование). Горячие данные хранятся в быстром кэше, холодные — в основном хранилище. Также обязательна денормализация: например, количество друзей или подписчиков хранится сразу в таблице пользователя (агрегат), а не вычисляется каждый раз запросом COUNT(*) при каждом просмотре профиля.

Простейшая авторизация на JWT с refresh-токенами. Для авторизации пользователя в высоконагруженной системе выбираем stateless подход на основе JWT (JSON Web Tokens). При успешном логине сервер авторизации (Auth Service) генерирует два токена: Access Token (срок жизни 15-30 минут) и Refresh Token (срок жизни 30 дней, хранится в защищенном HTTP-only cookie или в базе данных с возможностью отзыва). Access Token содержит идентификатор пользователя (sub), список ролей/прав (scope) и временные метки (iat, exp). Клиент отправляет Access Token в заголовке Authorization: Bearer для каждого API-запроса. Преимущества: не нужно хранить сессии на сервере (не тратится память и CPU, нет единой точки отказа Redis с сессиями), и нагрузка аутентификации распределяется на все сервисы, способные верифицировать подпись токена публичным ключом. Когда Access Token истекает, клиент обращается к специальному эндпоинту /refresh, отправляя Refresh Token. Auth Service проверяет Refresh Token, его валидность и, если все хорошо, выдает новую пару токенов. Отзыв осуществляется через blacklist неистекших Access токенов, хранящийся в быстром Redis с TTL, равным остатку жизни токена. Для микросервисной архитектуры обязательно использовать mTLS и внутренний сервис аутентификации (например, Keycloak или Dex), чтобы не дублировать логику проверки JWT в 50 сервисах.

Создание анкеты пользователя: валидация, санитизация, асинхронная запись. Процесс создания анкеты (User Profile) должен быть максимально быстрым для хорошего UX. Когда пользователь отправляет форму регистрации (имя, email, пароль, дата рождения, город, аватарка), API Gateway сначала проводит синхронную валидацию: проверка корректности email (регулярное выражение), минимальная длина пароля (8 символов), возраст (>=13 лет). Для защиты от атак типа XSS и SQL Injection данные проходят санитизацию — экранирование спецсимволов. Затем архитектор должен принять решение: делать синхронную запись в мастер-базу (для социальной сети допустима задержка 200-300 мс) или использовать асинхронную запись через очередь. В highload architect часто выбирают гибрид: критичные данные (логин, хеш пароля, уникальный ID) пишутся синхронно в таблицу пользователей, а “тяжелые” данные (аватарка, описание, интересы) кладутся в сообщение Kafka или RabbitMQ и асинхронно обрабатываются воркером, который денормализует их в другие хранилища (S3 для картинок, Elasticsearch для поиска). После синхронной записи пользователь сразу получает ответ 201 Created и может начать просмотр ленты, а асинхронная часть завершится через пару секунд незаметно. Такой подход разгружает ядро базы данных и позволяет переживать пиковые нагрузки регистрации (например, перед Новым годом).

Просмотр анкет: паттерн CQRS для разделения чтения и записи. Операции создания анкеты (write) и просмотра анкет (read) имеют кардинально разные паттерны нагрузки и требования к масштабированию. Для их оптимальной обработки применяется паттерн CQRS (Command Query Responsibility Segregation). В этой модели команды (create/update user) отправляются на один сервис и одну модель данных (обычно нормализованная реляционная БД, оптимизированная под целостность). А запросы (get user profile, search users) обслуживаются совершенно другим сервисом, который имеет свою денормализованную, подготовленную для быстрого чтения модель — например, реплику Elasticsearch или отдельную read-only БД с плоскими таблицами. Синхронизация между write и read моделями происходит асинхронно через событийную шину (event bus): после обновления пользователя сервис команд генерирует событие UserUpdatedEvent, которое ловится сервисом чтения и обновляет его представление. Такой подход позволяет масштабировать сервисы независимо: например, запустить 100 экземпляров read-сервиса под пиковую нагрузку чтения (вечером, когда все смотрят профили) и оставить 3 экземпляра write-сервиса. Также CQRS открывает возможность использовать для чтения абсолютно другие технологии, не подходящие для записи, например, GraphQL для гибких запросов или Materialized Views в Cassandra.

Стратегии кэширования: cache-aside, write-through, write-behind. Кэширование — это ключевой метод снижения нагрузки на базу данных в 10-100 раз. Cache-Aside (Lazy Loading) — самая распространенная стратегия: при чтении сначала проверяем кэш (Redis), если промах, загружаем из БД, записываем в кэш и возвращаем клиенту. При записи сначала обновляем БД, затем удаляем (или обновляем) ключ в кэше. Плюс: простота, минус: возможна гонка, когда старые данные снова попадают в кэш. Write-Through — при записи данные синхронно пишутся и в БД, и в кэш. Кэш всегда актуален, но задержка записи возрастает, и “холодный” кэш наполняется редко используемыми ключами. Write-Behind (Write-Back) — приложение пишет только в кэш, который асинхронно, пачками, сбрасывает данные в БД. Эта стратегия дает максимальную скорость записи (сотни тысяч операций в секунду), но при падении кэша данные теряются безвозвратно. Используется в системах, где допустима потеря данных (счетчики лайков) или есть репликация кэша. Highload architect часто комбинирует: для пользовательских сессий — write-through (нельзя потерять), для счетчика просмотров — write-behind.

Выбор кэш-сервера: Redis vs Memcached vs Hazelcast. Три основных кандидата для организации распределенного кэша в highload-системах. Memcached — простой и молниеносный in-memory key-value store. Лучший выбор для кэширования простых данных (HTML-фрагменты, результаты тяжелых SQL-запросов), когда не нужны структуры данных и persistence. Плюсы: максимальная производительность (до 1M операций в секунду на инстанс), масштабирование через клиентское шардирование. Минусы: нет репликации, нет постоянного хранилища. Redis — индустриальный стандарт для highload. Поддерживает сложные структуры: строки, хеши, списки, множества, sorted sets (идеально для лидербордов), битовые карты, HyperLogLog, потоки (для pub/sub). Есть master-slave репликация, Redis Cluster для горизонтального масштабирования, персистентность (RDB + AOF) и Lua-скрипты для атомарных операций. Минус: сложнее в настройке, чем Memcached. Hazelcast — это IMDG (In-Memory Data Grid), который предоставляет не только кэш, но и распределенные структуры данных, очереди, блокировки, вычисления прямо на узлах. Лучший выбор, когда кэш нужно интегрировать с Java-экосистемой и выполнять распределенную обработку данных на месте, не выгружая их.

Проблема “Собачий завал” (Thundering Herd) и как с ней бороться. Thundering Herd — это ситуация, когда множество клиентов одновременно запрашивают один и тот же ресурс, которого нет в кэше (например, после инвалидации). Все они видят cache miss и одновременно бросаются в базу данных или на медленный внешний сервис, создавая лавину запросов, которая может положить бэкенд. Типичный пример: популярная страница новости, которая инвалидируется, и тысячи пользователей запрашивают ее в одну секунду. Решения: 1) Mutex (блокировка на уровне клиента) — первый поток, обнаруживший промах, ставит блокировку на этот ключ (например, SETNX в Redis) и идет грузить данные, остальные ждут освобождения блокировки или сразу забирают уже загруженные данные из кэша. 2) Probabilistic Early Expiration — экспирация кэша не жесткая, а с вероятностью P (например, 10%) обновить заранее, не дожидаясь полного протухания. 3) Request Coalescing — на уровне API Gateway одинаковые запросы к одному ресурсу объединяются в один, остальные ждут ответа на этот первый. Алгоритм singleflight (Go) или cache-Aside с блокировкой в Java. В highload architect обязательно защищают критические пути кэшированием с блокировками, иначе “собачий завал” случается в самый неподходящий момент (после перезапуска кэша или сбоя сети).

Управление сессиями в кластере без единой точки отказа. Традиционный подход — хранить сессии в оперативной памяти веб-сервера — не работает в горизонтально масштабируемом кластере, так как запросы от одного пользователя могут попадать на разные серверы. Решение проблемы “липких сессий” (sticky sessions) через балансировщик — это антипаттерн, так как падение одного сервера приводит к потере всех сессий его пользователей. Правильное решение — централизованное хранилище сессий с репликацией и автоматическим фейловером. Лучшая практика: использовать Redis Cluster или Redis Sentinel. Каждая сессия — это хеш в Redis с TTL, равным времени жизни сессии (например, 1 час). При каждом запросе сервер обращается к Redis за данными сессии. Чтобы снизить латентность и нагрузку на Redis, применяют “сессионный кэш” на уровне приложения: сессия вычитывается из Redis и локально кэшируется на сервере на 30-60 секунд с асинхронным обновлением. Для абсолютной отказоустойчивости используют паттерн Lease: сервер арендует сессию на N секунд, и если сервер упал, другой сервер сможет ее забрать через N секунд. В случае полного падения Redis (очень редко при кластере) архитектор должен предусмотреть fallback: либо отказать в обслуживании с 503 ошибкой, либо перевести систему в режим “read-only” с памятью о предыдущей аутентификации.

Паттерн Saga для распределенных транзакций в микросервисах. В монолите ACID-транзакции гарантируют атомарность: либо все операции успешны, либо откат. В микросервисной архитектуре, где данные размазаны по разным сервисам и базам данных, классическая двухфазная фиксация (2PC) неприменима из-за блокировок и низкой производительности. Saga — это паттерн, который заменяет единую транзакцию последовательностью локальных транзакций, каждая из которых обновляет свой сервис и публикует событие (message). Если шаг саги не удается, запускаются компенсирующие транзакции (compensation), которые отменяют предыдущие шаги. Существует две реализации: Choreography (хореография) — сервисы публикуют события и слушают события друг друга, нет центрального координатора. Просто, но сложно отслеживать. Orchestration (оркестрация) — есть центральный оркестратор (saga orchestrator) в виде отдельного сервиса или библиотеки (например, Camunda, Temporal), который командует шагами и обрабатывает сбои. Пример: процесс заказа в e-commerce: Saga Orchestrator вызывает: 1) Payment Service (заблокировать деньги), 2) Inventory Service (зарезервировать товар), 3) Shipping Service (оформить доставку). Если на шаге 2 инвентарь не прошел, оркестратор вызывает компенсацию в Payment Service (вернуть деньги).

Apache Kafka: устройство, партиционирование и гарантии доставки. Apache Kafka — это распределенный event streaming платформа, де-факто стандарт для highload-систем. В отличие от очередей (RabbitMQ), Kafka хранит сообщения на диске несколько дней и воспроизводит их заново. Ключевая концепция — topic, который разбит на partitions. Партиции — это упорядоченные и неизменяемые последовательности сообщений. Гарантия порядка сообщений действует ВНУТРИ одной партиции, но не между партициями. Продюсер (producer) решает, в какую партицию писать: round-robin, по ключу (хешу) или кастомный партиционер. Консьюмеры (consumers) объединяются в consumer group — каждая партиция читается только одним консьюмером внутри группы, что позволяет горизонтально масштабировать обработку. Гарантии доставки: at-most-once (возможна потеря), at-least-once (возможны дубли, реализуется через параметр enable.auto.commit=false и ручное сохранение offset) и exactly-once (строго один раз) — включается через транзакционный продюсер и идемпотентность. Для highload-архитектора критично: количество партиций топика должно быть кратно количеству серверов брокеров для равномерного распределения и не может быть уменьшено без пересоздания топика, поэтому закладывается с запасом (например, 200-300 партиций на самый нагруженный топик).

Idempotency ключи для защиты от повторной обработки сообщений. В распределенных системах сообщения из очереди (Kafka, RabbitMQ) могут быть доставлены дважды: из-за перезапуска консьюмера, сетевых таймаутов, ребалансировки группы. Обработка одного сообщения дважды (например, списание денег, отправка email, начисление бонуса) может привести к катастрофе. Защита — идентификатор идемпотентности (idempotency key). При отправке сообщения продюсер генерирует уникальный идентификатор, например UUID:order_123:attempt_1 или HMAC(userId + operationId + timestamp). Консьюмер перед обработкой сохраняет этот ключ в хранилище (Redis + TTL 24 часа, или таблица БД с уникальным индексом) и проверяет, не обрабатывался ли такой ключ. Если ключ уже есть, консьюмер просто подтверждает получение и пропускает обработку. Второй подход — оптимистичная версионность в базе: перед обновлением записи проверяем version. Если version не совпадает с ожидаемым, значит, сообщение пришло повторно или запись уже изменена. Для высоконагруженных систем с миллионом идемпотентных операций в час лучше использовать Redis с persistency или выделенный сервис Idempotency Service на базе DynamoDB или Cassandra с TTL. Правило: все операции, которые не являются естественно идемпотентными (например, GET или DELETE), должны защищаться идемпотентностью на уровне архитектуры.

Золотые сигналы мониторинга по методике Google SRE. Site Reliability Engineering (SRE) от Google выделяет четыре “золотых сигнала”, которые необходимо измерять для каждого сервиса в highload-системе: Latency (время обработки запроса, разделяя на успешные и ошибочные ответы — ошибки часто обрабатываются быстрее, что искажает среднее значение), Traffic (количество запросов в секунду RPS, с привязкой к пользователям или бизнес-транзакциям), Errors (доля запросов, завершившихся с ошибкой 5xx, 4xx (если это ваша вина), явные таймауты), Saturation (насколько сервис “заполнен” — загрузка CPU, memory usage, сетевые очереди, лимит соединений). Помимо сигналов, SRE вводят Service Level Objectives (SLO) и Service Level Indicators (SLI). SLI — это измеримый сигнал, например, “доля запросов с задержкой меньше 100 мс за последние 5 минут”. SLO — целевое значение для SLI, например, “99.9% запросов имеют Latency < 100 мс”. Когда SLO нарушается, это триггер для бурной реакции или автоматического отката. Highload architect должен настроить дашборды именно на эти четыре сигнала, а не на тысячи метрик, которые скрывают реальные проблемы.

Распределенная трассировка (Distributed Tracing) с Jaeger или Zipkin. В микросервисной архитектуре один запрос пользователя может проходить через 10-20 сервисов: API Gateway -> Auth Service -> User Profile -> Friends Service -> Feed Service -> Recommendation Service. Когда возникает задержка, понять, где именно она происходит, без трассировки невозможно. Distributed Tracing решает эту проблему: при входе запроса генерируется глобальный trace_id (например, UUID), который передается через HTTP-заголовки (обычно X-Request-Id или X-B3-TraceId согласно стандарту Zipkin B3). Каждый сервис, обрабатывая запрос, добавляет свои spans (отрезки времени для определенного действия: вызов БД, вызов внешнего API, обработка бизнес-логики). Все spans с одним trace_id собираются агентом-коллектором (например, Jaeger Agent или Zipkin Collector) и отправляются в UI (Jaeger Query, Zipkin). Архитектор должен внедрить автоматическое инструментирование через библиотеки-инструментаторы: OpenTelemetry (стандарт де-факто), автоматически оборачивающие HTTP-клиенты, драйверы БД и очереди. Обязательное требование: семплирование (sampling). Нельзя трассировать 100% запросов в highload (это создаст огромную нагрузку). Используется вероятностное семплирование (1-5%) или семплирование на основе ошибок (ошибочные запросы трассируются всегда).

Метрики и дашборды в Prometheus + Grafana. Прометей (Prometheus) — это стандарт сбора метрик в высоконагруженных системах, построенный на модели pull (сам Prometheus опрашивает endpoints метрик сервисов по HTTP). Каждый микросервис должен экспортировать метрики на порту /metrics в формате, понятном Prometheus (простые текстовые форматы с метками). Типы метрик: Counter (счетчик, только увеличивается: количество запросов, ошибок), Gauge (значение может расти и падать: текущая память, количество горутин), Histogram (распределение значений: задержки запросов по бакетам 0.1s, 0.5s, 1s, 5s) и Summary (квантили). Prometheus хранит временные ряды на локальном диске (эффективно, но не бесконечно) и должен быть шардирован для больших кластеров через Thanos или Cortex. Grafana используется для визуализации: настраиваются дашборды с панелями графов, таблиц, тепловых карт (heatmaps) для латентностей. Обязательный паттерн для highload architect: настраивать оповещения (alerts) в Prometheus на основе золотых сигналов и SLO, отправляя их в Alertmanager, который может маршрутизировать в PagerDuty, Telegram, Slack.

Логирование в высоконагруженной системе: ELK Stack vs Loki. Традиционный стек ELK (Elasticsearch + Logstash + Kibana) мощный, но тяжелый и ресурсоемкий. Для highload систем с терабайтами логов, где нужен быстрый grep-подобный поиск по логам, все чаще выбирают Loki от Grafana Labs. Loki не индексирует содержимое логов полностью, а индексирует только метки (labels), такие как service_name, pod, level, а сами логи сжимает (gzip) и хранит в объектном хранилище (S3, GCS). Это делает Loki в 10-100 раз дешевле Elasticsearch при аналогичной нагрузке. Агент для сбора логов — Promtail или FluentBit, который читает логи из stdout/stderr контейнеров (Kubernetes), добавляет метки и отправляет в Loki. Highload architect определяет стратегию ротации и хранения: логи низкого уровня (DEBUG, INFO) хранить 3 дня, WARNING и ERROR — 30 дней, CRITICAL — 1 год. Структурированное логирование в формате JSON обязательно (например, с помощью logrus или zerolog в Go, logstash-logback-encoder в Java): так можно легко парсить поля (user_id, trace_id, duration_ms, error) и делать быстрые фильтры в Loki или Kibana. Никогда не логируйте пароли, токены, персональные данные (PII) — это нарушение GDPR и угроза безопасности.

Паттерн Circuit Breaker для защиты cascading failures. Circuit Breaker (Автоматический выключатель) — паттерн, предотвращающий каскадные отказы (cascading failures) в распределенной системе. Представьте, что сервис A вызывает сервис B, который начинает отвечать медленно (с таймаутами). Без Circuit Breaker все потоки A будут ждать и накапливаться, исчерпав пул потоков A, что положит сервис A (и другие сервисы, которые на него полагаются). Circuit Breaker оборачивает вызов удаленного сервиса и имеет три состояния: CLOSED (замкнут, нормальная работа, вызовы проходят, счетчик ошибок растет), OPEN (разомкнут, все вызовы мгновенно возвращают ошибку без реального вызова, чтобы дать B восстановиться), и HALF-OPEN (полуоткрыт, после таймаута в состоянии OPEN пропускается ограниченное количество тестовых вызовов; если они успешны — переходим в CLOSED, если нет — снова в OPEN). Библиотеки реализаций: Hystrix (Netflix, ныне в maintenance), Resilience4j (современная замена для Java/Scala), Polly для .NET, go-resiliency для Go. В настройках архитектор задает: порог ошибок (например, 50% ошибок за последние 10 секунд), timeout в миллисекундах на каждый вызов, размер буфера скользящего окна (например, 20 запросов), время в OPEN состоянии (например, 30 секунд для восстановления).

Retry with Exponential Backoff и Jitter. В распределенных системах многие сбои временны: network glitch, временная недоступность leader БД, перезапуск сервиса. Повторная попытка (retry) через некоторое время часто решает проблему. Однако простые повторные попытки с фиксированной задержкой (retry every 1 sec) могут создать “self-denial-of-service”, когда все клиенты одновременно повторно стучатся в только что восстановившийся сервис и снова его перегружают. Правильная стратегия — Exponential Backoff with Jitter. Формула: delay = min(max_delay, initial_delay * (2^{attempt} - 1) + random_jitter). Например, первая попытка через 100 мс, вторая через 200 мс, третья через 400 мс, четвертая через 800 мс, пятая через 1600 мс. Jitter — случайное небольшое отклонение (+/- 20% от задержки), чтобы распараллелить запросы клиентов во времени. Максимальное количество повторных попыток — не более 5, иначе пользователь будет ждать слишком долго. Важно: retry нужно делать только для идемпотентных операций (GET, PUT, DELETE идиемпотентны, POST — нет, если не защищен). В противном случае повтор может привести к задвоению. Библиотеки с реализацией: backoff в Google APIs, retry в Resilience4j, exponential-backoff в Python. Highload architect должен настраивать retry на уровне клиента каждого сервиса, а на уровне API Gateway retry быть не должно, иначе внешний клиент просто умрет от таймаутов.

Deadline Propagation и Timeout Budgeting. В цепочке микросервисов A -> B -> C -> D каждый вызов должен иметь ограничение по времени (timeout). Если у A общий таймаут на ответ пользователю 1 секунда, а B тратит 900 мс, на C остается 100 мс, на D — 0 мс, то D неизбежно даст таймаут, но ответ может уже не успеть к пользователю. Deadline Propagation — это передача оставшегося бюджета времени от вызывающего сервиса к вызываемому. Обычно deadline передается в метаданных запросах (grpc metadata, HTTP headers). Входящий сервис вычитывает deadline, и перед каждым исходящим вызовом вычисляет: remaining_deadline = original_deadline - now(), затем устанавливает timeout для вызова как min(remaining_deadline - safety_margin, max_allowed_call_timeout). Safety margin (100-200 мс) нужен, чтобы успеть выполнить пост-обработку ответа. Без этой практики в сложных графах вызовов доля таймаутов растет нелинейно, а время ответа становится непредсказуемым. Имплементации: gRPC поддерживает propagation через контекст, в HTTP можно использовать заголовок Grpc-Timeout или кастомный X-Deadline-At с Unix timestamp. Еще один трюк — Budgeted retries: вы отводите на повторные попытки только часть от оставшегося времени, и если не укладываетесь, отдаете ошибку (не пытайтесь бесконечно).

Graceful Shutdown и Health Checks в Kubernetes. В кластере Kubernetes поды (контейнеры) постоянно пересоздаются: при rollout, под нагрузкой автоскейлинга, при падении узла. Чтобы пользователи не замечали этих перестроек, каждый сервис должен корректно завершаться (graceful shutdown). Процесс: 1) Kubernetes отправляет сигнал SIGTERM поду. 2) Приложение перестает принимать новые запросы (переводит порт из состояния LISTEN в DRAINING или отключается от балансировщика). 3) Приложение ждет завершения уже обрабатываемых запросов (in-flight requests) в течение terminationGracePeriodSeconds (по умолчанию 30 секунд). 4) Если за это время запросы не завершились, они обрываются (hard kill). Для этого нужно: в коде обработчик сигналов, пул соединений, закрываемый после завершения active запросов. Второй аспект — liveness и readiness probes. Readiness probe (начальная) — проверяет, готов ли сервис принимать трафик. Например, если сервис прогревает кэш или коннектится к БД, readiness probe вернет 200 только через 15 секунд. Liveness probe (постоянная) — проверяет, жив ли сервис (не deadlock). Если liveness probe падает, Kubernetes перезапустит под. Анти-паттерн: делать liveness probe слишком тяжелой (проверять БД, Redis — при сбое этих зависимостей под перезапустится, но проблема-то на уровне БД, перезапуск приложения не решит её, он только усугубит нагрузку).

Цель ДЗ: декомпозиция и создание базовой архитектуры. Первое домашнее задание направлено на развитие ключевых навыков highload architect: декомпозиции предметной области и построения элементарной архитектуры проекта. Вам необходимо разработать создание и просмотр анкет пользователей в социальной сети. Это база, на которой будут строиться все следующие ДЗ (лента новостей, чаты, рекомендации). Вы должны показать умение выделить сущности, их взаимосвязи, выбрать протоколы взаимодействия и набросать схему компонентов. Ключевой навык — не углубляться в детали реализации (код, базы данных), а на высоком уровне абстракции описать, как система будет работать при нагрузке в 10 000 одновременных пользователей, с учетом дальнейшего роста в 100 раз.

Функциональные требования к социальной сети (часть 1). Требования к системе из домашнего задания: 1) Простейшая авторизация пользователя — базовая аутентификация (логин/пароль) без поддержки OAuth, двухфакторной авторизации и восстановления пароля на данном этапе. Достаточно принимать логин/пароль, проверять их (желательно с хешированием пароля по алгоритму bcrypt или scrypt) и отдавать сессионный токен (JWT или случайную строку в куках). 2) Создание пользователя — API endpoint POST /v1/users с полями: логин (уникальный), пароль, полное имя, дата рождения, описание профиля, ссылка на аватар. Поля — по желанию, но логин и пароль обязательны. Необходима валидация: логин не менее 3 символов, пароль не менее 6 символов, дата рождения в прошлом. 3) Просмотр анкет — API endpoint GET /v1/users/{id} возвращает публичную информацию о пользователе (кроме пароля). А также, вероятно, GET /v1/users с пагинацией для списка пользователей.

Нефункциональные требования и ограничения. Скрытые требования, которые нужно учесть при архитектуре: Система должна быть готова к нагрузке 1000 RPS на создание пользователей и 10 000 RPS на просмотр анкет (читаем гораздо чаще, чем пишем). Время отклика API: 99% запросов на просмотр должны выполняться менее 100 мс, на создание — менее 300 мс. Доступность (availability): 99.95% (около 22 минут простоя в месяц). Система должна быть спроектирована с возможностью горизонтального масштабирования: добавление новых серверов должно линейно увеличивать пропускную способность. Data retention: данные пользователей должны храниться вечно (или до удаления самого пользователя). Безопасность: пароли не хранятся в открытом виде, используется HTTPS, защита от брутфорса (rate limiting на /login). Также система должна обрабатывать ошибки: если база данных недоступна, API должен возвращать понятную ошибку 503, а не падать.

Архитектурная схема решения (High-Level Design). Предлагаемая архитектура для ДЗ: Клиент (Web/Mobile) → API Gateway / Reverse Proxy (NGINX) → Сервис User Service (на Go, Java, Python) → Кластер БД PostgreSQL с репликацией master-slave. Дополнительно: кэш Redis между User Service и БД для кеширования профайлов пользователей (TTL 5 минут). API Gateway выполняет: SSL termination, rate limiting (100 запросов в секунду на IP), маршрутизацию на /users -> User Service, и возможно агрегацию ответа (если данные профиля хранятся в нескольких таблицах). User Service реализует бизнес-логику: проверка уникальности логина, хеширование пароля, валидация, маппинг из DTO в Entity. Для просмотра анкет: при запросе сначала смотрит в Redis (ключ user:{id}), если нет — в PostgreSQL, затем кладет в Redis. Для создания: сначала валидирует, проверяет уникальность (запрос в БД с блокировкой), затем вставляет новую строку, и инвалидирует возможный кэш по этому ID (если вдруг кто-то успел закешировать несуществующего пользователя).

Модель данных для PostgreSQL. Для реализации используем одну таблицу users с полями: id BIGSERIAL PRIMARY KEY, login VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL (храним bcrypt хеш), full_name VARCHAR(255), birth_date DATE, bio TEXT, avatar_url TEXT, created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(). Индексы: по id (уже первичный ключ), уникальный индекс по login для быстрого поиска при авторизации. Для масштабирования в будущем возможно партиционирование по диапазону id (например, 1-10M в партиции 1, 10M-20M в партиции 2), но на старте достаточно одной таблицы. Обратите внимание: не храните количество друзей, лайки и прочее — это отдельные домены. Будет плюсом, если вы добавите soft delete: поле deleted_at TIMESTAMP, чтобы не терять данные при удалении. SQL миграции управлять через Flyway или Liquibase.

API спецификация (OpenAPI 3.0) для User Service. Пример спецификации эндпоинтов (должна быть частью архитектурного документа): POST /api/v1/register — Body: { "login": "john_doe", "password": "securePass123", "full_name": "John Doe", "birth_date": "1990-01-01", "bio": "...", "avatar_url": "..." } — Ответ: 201 Created с Location header /api/v1/users/{id} и телом { "id": 12345, "login": ... }. POST /api/v1/login — Body: { "login": "john_doe", "password": "..." } — Ответ: 200 OK c { "token": "jwt_token_here", "user": { ... } }. GET /api/v1/users/{id} — Ответ: 200 OK с профилем пользователя (без пароля). GET /api/v1/users?limit=20&offset=0 — пагинированный список пользователей. Все ошибки возвращают стандартный формат: { "error": "code", "message": "description" }. Ошибки: 400 — валидация, 401 — неверный пароль, 404 — пользователь не найден, 409 — логин уже занят, 500 — внутренняя ошибка сервера. Обратите внимание: логин и пароль для безопасности должны передаваться только по HTTPS.

Инструкция по запуску и проверке ДЗ. Студент должен предоставить: 1) Репозиторий с кодом (GitHub/GitLab) — структура проекта (backend на любом языке). 2) Dockerfile для сборки сервиса, docker-compose.yml, который поднимает PostgreSQL, Redis и сам сервис. 3) README с описанием архитектуры (почему выбрана такая схема), последовательность запуска, примеры curl-запросов. 4) Unit-тесты на бизнес-логику (валидацию, хеширование, проверку уникальности). Обязательно наличие автоматических тестов интеграции, которые проверяют реальную работу с БД (testcontainers). Дополнительное задание: написать простой нагрузочный тест с wrk или vegeta, который показывает, что система держит 1000 RPS на чтение при задержке < 50 ms. Критерии оценки: чистота кода, наличие graceful shutdown, обработка ошибок, отсутствие SQL-инъекций, использование connection pooling для БД, корректная работа с кэшем Redis (инвалидация при обновлении).