System Design: основное

Что такое System Design в контексте backend-разработки

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

Простое определение: System Design — это ответ на вопрос "как мне построить систему, которая может обслуживать миллионы пользователей, хранить терабайты данных, отказоустойчива к сбоям и имеет приемлемую latency?"

В контексте backend-разработки на Java это включает выбор:

• Архитектурного паттерна (микросервисы, монолит, serverless)
• Технологий хранения данных (SQL, NoSQL, key-value)
• Паттернов масштабирования (репликация, шардирование, кеширование)
• Инструментов интеграции (брокеры сообщений, API gateways, load balancers)
• Подходов к отказоустойчивости и мониторингу

Роль System Design в реальной продуктовой разработке

На практике, когда команда начинает работать над новым продуктом или решает масштабировать существующий, инженеры проводят сессии по проектированию архитектуры. Эти сессии помогают избежать дорогостоящих архитектурных ошибок на поздних этапах развития. Senior разработчик должен возглавлять эти дискуссии, предлагать решения, которые работают не только сейчас, но и через год-два, когда нагрузка вырастет в 10 раз.

System Design — это про долгосрочное мышление:

• Сегодня у вас 1000 пользователей и простая архитектура работает
• Завтра 100 000 пользователей, и нужны кеши, база для чтения отдельно, брокер сообщений
• Через год 1 млн пользователей, и архитектура должна была предусмотреть шардирование с самого начала

Отличие архитектурных разговоров на работе от собеседований

На собеседовании System Design отличается тем, что это симуляция: интервьюер даёт расплывчатую задачу, вы должны самостоятельно задать правильные вопросы, сделать разумные допущения и в течение 45 минут вывести логичную архитектуру на доске или в виртуальном whiteboard.

На работе:

• У вас есть уже готовые требования, документация, данные по существующим нагрузкам
• Обсуждение может занять несколько встреч
• Можно полагаться на коллег и их опыт с конкретными технологиями
• У вас есть доступ к аналитике, метрикам, логам

На собеседовании:

• Требования намеренно неполные
• 45–60 минут на весь процесс: требования + архитектура + обсуждение trade-off'ов
• Все значения вы вычисляете сами (RPS, объём данных, количество серверов)
• Интервьюер оценивает ваш процесс мышления, а не точность архитектуры

Что рекрутеры и интервьюеры ждут от Senior Java Backend инженера

Какие скиллы проверяются

System Design раунд на собеседовании Senior инженера проверяет несколько категорий компетенций:

1. Инженерное мышление и структурированность. Интервьюер хочет видеть, что вы не прыгаете случайно между идеями, а следуете логичному процессу: требования → нагрузки → компоненты → масштабирование. Это показывает, что в реальной жизни вы сможете спроектировать систему, которая не развалится в production.

2. Математические и практические вычисления. Умение делать back-of-the-envelope оценки (примерные расчёты на основе простых предположений) показывает, что вы способны понять масштаб проблемы. Интервьюер ценит, что вы можете сказать: "10 млн пользователей, каждый день 10 млрд запросов, это примерно 100 000 RPS в среднем" и на основе этого выбрать архитектуру.

3. Знание технологий и практических решений. На уровне Senior ожидается, что вы знаете, когда использовать PostgreSQL, когда Cassandra, когда Redis. Это не про то, чтобы знать все инструменты, а про то, чтобы понимать trade-off'ы и уметь объяснить выбор.

4. Коммуникация и trade-off анализ. Не существует идеального решения. Лучший кандидат показывает, что понимает: выбрав PostgreSQL, вы получаете ACID, но теряете горизонтальное масштабирование; выбрав Kafka, вы решаете проблему асинхронных очередей, но добавляете сложность в систему. Senior инженер озвучивает эти trade-off'ы вслух и обсуждает с интервьюером, какой выбор более приемлем в данных условиях.

5. Product thinking. На уровне Senior ожидается, что вы не только думаете о технических ограничениях, но и о том, как система служит пользователю. Например, при проектировании ленты новостей важно понимать, что задержка в 1 секунду может раздражать, но задержка в 100 мс — это OK. Это влияет на выбор между eventual consistency и strong consistency.

Какие уровни глубины ожидаются от middle vs senior

Middle-level разработчик на System Design собеседовании может рассказать про основные компоненты системы (backend, DB, cache), назвать несколько технологий и выбрать одну. Ответ поверхностный, но логичный.

Senior-level инженер:

• Спрашивает уточняющие вопросы, которые покрывают реальные требования
• Дает рассчитанные оценки нагрузок (не просто "много пользователей", а конкретные RPS и GB в год)
• Предлагает несколько альтернатив архитектуры, обсуждает их плюсы и минусы
• Рассказывает про edge cases и проблемы масштабирования (например, hot keys в Redis при неправильном шардировании)
• Обращает внимание на observability, security, disaster recovery — не только на "как это работает", но и на "что будет, если что-то пойдёт не так"
• Говорит про эволюцию системы: "первый год ей хватит монолита, но когда нагрузка вырастет в 10 раз, нужно будет перейти на микросервисы"

Как проявляется product thinking на system design

Product thinking — это умение видеть систему через призму пользователя и бизнеса, а не только через призму технических ограничений.

Примеры:

• При проектировании чата вы спрашиваете: "Критична ли доставка сообщений в порядке FIFO или eventual consistency приемлема?" Это зависит от того, ценит ли пользователь порядок или просто хочет получить все сообщения.
• При проектировании URL shortener вы обсуждаете: "Нужна ли поддержка custom slugs (вроде bit.ly/myurl)? Это может привести к коллизиям, но пользователи это иногда хотят."
• При проектировании платёжной системы вы думаете: "Если платёж завис, что хуже — заблокировать пользователя с сообщением 'попробуйте позже' или показать оптимистичное сообщение, но потом откатить транзакцию?" Это зависит от бизнес-метрик.

Senior инженер демонстрирует product thinking, когда в середине архитектурного обсуждения говорит: "Подождите, давайте уточним, может ли пользователь жить с задержкой в 5 минут? Если да, это сильно упрощает архитектуру."

Типовой формат задач на собеседовании

Примеры задач и их формулировки

System Design задачи на собеседованиях обычно звучат расплывчато и просто:

• "Спроектируй чат, как в Telegram"
• "Спроектируй ленту новостей"
• "Спроектируй URL shortener"
• "Спроектируй сервис загрузки видео"
• "Спроектируй систему хранения файлов"
• "Спроектируй сервис микротранзакций между пользователями"

Формулировка намеренно неполная. Задача кандидата — спросить конкретику.

Как обычно задают: формулировка, ограничения по времени, формат диалога

Интервьюер обычно говорит:

• "Вот задача: спроектируй ленту новостей. У тебя есть 45 минут. Давай ты начнёшь с требований."
• Дальше вы рисуете на доске/whiteboard и обсуждаете с интервьюером в реальном времени
• Интервьюер может перебивать и задавать уточняющие вопросы типа: "А если трафик вырастет в 100 раз, что будет?"
• Примерно через 30 минут интервьюер может предложить deep dive в какую-то конкретную часть (например: "Давай подробнее разберём, как масштабировать чтение из БД")

Ограничения по времени жёсткие: 45 минут — это меньше, чем кажется. Если вы 20 минут говорили про требования, то на архитектуру у вас осталось только 25 минут.

Что считается успешным ответом на уровне senior

Успешный ответ на уровне Senior не означает идеальную архитектуру. Это означает:

1. Вы задали 5–10 уточняющих вопросов про требования и нагрузки.
2. Вы сделали видимые, разумные вычисления (примерно такие: если 1 млн DAU, то в пиковый час это примерно 100 000 RPS, каждый запрос примерно 1 KB, значит в секунду 100 MB трафика).
3. Вы нарисовали ясную high-level архитектуру на доске с 5–7 основными компонентами (gateway, backend, DB, cache, message broker и т.д.).
4. Вы обсудили несколько важных trade-off'ов (например: "Если нам нужна сильная консистентность, используем PostgreSQL, но это усложнит масштабирование; если приемлема eventual consistency, можем использовать NoSQL и масштабировать горизонтально").
5. Вы обсудили масштабирование по чтению (кеши, read replicas) и по записи (очереди, асинхронная обработка).
6. Вы не запутались в деталях реализации, а оставались на уровне архитектурных решений.
7. Вы логично ответили на 2–3 уточняющих вопроса от интервьюера (тип "а что, если...?").

Интервьюер не ожидает, что вы спроектируете идеальную, боевую систему. Он оценивает ваш процесс, логику и умение общаться.

Обязательные шаги при ответе: framework ответа

Сбор и уточнение функциональных требований

Первый шаг — никогда не начинайте рисовать архитектуру! Сначала спросите про требования. Это показывает структурированность и опыт.

Какие вопросы нужно задать:

• Кто пользователи системы? (в контексте задачи могут быть пользователи, администраторы, third-party системы)
• Какие основные operations/операции? (для чата: отправить сообщение, получить историю; для ленты: постить, читать ленту)
• Какой scope: только одна страна или multiregion? Только веб или мобильные приложения?
• Есть ли real-time требования или батч-обработка приемлема?
• Сколько времени на консистентность? Нужна ли strong consistency (ACID) или eventual consistency (BASE) приемлема?

Примеры формулировок вашего вопроса:

• "Давайте уточним scope: в системе есть только пользователи, которые отправляют друг другу сообщения, или также есть группы/каналы?"
• "Нужна ли история всех сообщений или можно удалять сообщения после истечения срока?"
• "Пиковая нагрузка в одной стране или это глобальная система?"

Как фиксировать границы системы:

• Явно скажите: "Итак, я понял, что нам нужно реализовать: 1) отправку сообщений, 2) получение истории, 3) real-time уведомления о новых сообщениях. Правильно?"
• Определите, что NOT в scope: "Я не буду проектировать video calling, это отдельная система, верно?"
• Это показывает, что вы структурированы и не будете проектировать случайные features.

Сбор нефункциональных требований

Нефункциональные требования (NFR) — это performance, availability, scalability, latency, consistency. Эта часть часто упускают кандидаты, и это ошибка.

Нагрузка:

• Сколько пользователей? (total, active, concurrent)
• Сколько операций в секунду? (RPS — requests per second)
• Какой рост ожидается? (в 2 раза в год или в 10 раз в месяц?)
• Когда пиковая нагрузка? (все пользователи в одно время или распределены по часовым поясам?)

Пример: "Давайте скажем, что у нас есть 1 млн пользователей. В активные часы (часовой пояс UTC) примерно 100 000 одновременно онлайн. Пиковая нагрузка — примерно 100 000 RPS на чтение."

SLA и performance metrics:

• Latency: какова должна быть p99 (99-й перцентиль) задержка? Например, для чата важно, чтобы сообщение доставилось за < 1 секунды.
• Availability: 99% (примерно 14.4 минуты простоя в день) или 99.9% (около 86 секунд в день)?
• Durability: все ли данные должны быть сохранены или можно потерять часть сообщений в крайних случаях?

Пример диалога: "Скажем, SLA — 99.9% availability и p99 latency на чтение < 500 ms."

Геораспределённость:

• Система в одном регионе (datacenter) или нужна multiregion?
• Если multiregion, нужна ли active-active (оба региона обслуживают трафик) или active-passive (один основной, другой на backup)?

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

• Бюджетные ограничения иногда влияют на выбор технологий (managed services дороже, чем self-hosted)
• Constraints по срокам: "Нужно запустить за месяц" влияет на выбор известных, проверенных решений вместо experimental

Оценка примерной нагрузки и объёмов данных: back-of-the-envelope вычисления

Back-of-the-envelope (BOTE) вычисления — это примерные расчёты, которые показывают масштаб задачи. Интервьюер ценит, что вы можете быстро прикинуть на бумаге, сколько нужно памяти, дискового пространства, пропускной способности.

Простые примеры:

1. Чат: сколько данных в год?

   • 1 млн пользователей, средний пользователь отправляет 10 сообщений в день
   • 1 млн * 10 = 10 млн сообщений в день
   • Среднее сообщение: 100 bytes + metadata (timestamp, sender_id, receiver_id) ~ 200 bytes
   • 10 млн * 200 bytes = 2 GB в день
   • В год: 2 GB * 365 = 730 GB ~ 1 TB в год
   • Вывод: за 10 лет нам нужно примерно 10 TB на хранение сообщений. Это разумно для одной базы, но нужно думать про архивирование.

2. Ленты новостей: сколько RPS нам нужно обслужить?

   • 1 млн пользователей, в активный час 100 000 онлайн
   • Пользователь обновляет ленту примерно каждые 10 секунд в среднем
   • 100 000 / 10 = 10 000 RPS на чтение (обновление ленты)
   • Каждый пост из ленты ~ 1 KB, ленты на экране ~ 20 постов = 20 KB на запрос
   • 10 000 RPS * 20 KB = 200 MB/s трафика (вполне управляемо)

3. URL shortener: сколько памяти на кеш?

   • 1 млн коротких ссылок в день
   • 80% запросов идут на 20% ссылок (правило Парето)
   • Если кешировать эти 20%, то 1 млн * 0.2 = 200 000 ссылок
   • Каждая ссылка: 8 bytes (id) + 100 bytes (long url) ~ 200 bytes
   • 200 000 * 200 bytes = 40 MB памяти. Это очень мало, хватит даже одного Redis на однопроцессорной машине.

Зачем интервьюеру видеть эти вычисления:

• Это показывает, что вы не проектируете "на глаз", а делаете обоснованные выводы
• Это помогает понять, какие компоненты архитектуры критичны (например, в примере с URL shortener выяснилось, что кеш очень мал, значит можно использовать простой Redis)
• Это помогает интервьюеру глубже копать в нужное место (если вы сказали, что нужно 10 TB, интервьюер может спросить: "А как мы будем шардировать базу на 10 TB?")

Формирование high-level архитектуры

Основные компоненты систем backend, которые вы должны знать и уметь размещать в архитектуре:

1. Client layer: веб-браузер, мобильное приложение, third-party клиент. На собеседовании часто не обсуждается детально, но важно помнить.

2. API Gateway / Load Balancer: точка входа для всех запросов. Распределяет нагрузку между несколькими инстансами backend сервиса. Важен для масштабирования.

3. Backend service: ваше приложение на Java/Kotlin. Обычно stateless, можно запустить несколько копий. На диаграмме обозначьте как "Backend (N instances)".

4. Database (primary): основное хранилище данных. Для данных, требующих ACID (например, балансы аккаунтов, истории платежей). Обычно одна primary, несколько replicas для чтения.

5. Cache: Redis или Memcached. Хранит часто читаемые данные в памяти. Быстро, но данные могут быть потеряны при перезагрузке.

6. Message Broker: Kafka, RabbitMQ, или AWS SQS. Нужен для асинхронной обработки, decoupling компонентов, гарантирования доставки сообщений.

7. Search engine: Elasticsearch для полнотекстовой индексации. Если нужно быстро искать по большим объёмам текста (например, поиск в ленте).

8. Object Storage / File System: S3, GCS или local file system. Для хранения файлов, картинок, видео.

9. Secondary (read) database или NoSQL: если нужны данные в другом формате или с другой консистентностью. Например, Cassandra для высокой write throughput, ElasticSearch для полнотекстового поиска.

Общая схема взаимодействия компонентов:

[Client] -> [API Gateway / LB] -> [Backend Service (N instances)]
                                       |
                                       +-> [Primary DB]
                                       |    |
                                       |    +-> [Read Replicas]
                                       |
                                       +-> [Redis Cache]
                                       |
                                       +-> [Message Broker (Kafka)]
                                       |
                                       +-> [Search Engine (ES)]
                                       |
                                       +-> [Object Storage (S3)]

На собеседовании не нужно рисовать лишний сложности. Начните с простой архитектуры (API GW -> Backend -> DB), а потом добавляйте компоненты по мере обсуждения требований и масштабирования.

Обсуждение выбора технологий и trade-off'ов

На уровне Senior ожидается, что вы не просто называете технологию, но и объясняете, почему. Вот типичные trade-off'ы, которые часто обсуждаются:

1. RDBMS (PostgreSQL, MySQL) vs NoSQL (MongoDB, Cassandra)

   RDBMS плюсы:

   • ACID гарантии (Atomicity, Consistency, Isolation, Durability)
   • Мощные запросы (JOIN'ы, агрегации)
   • Хорошо знакомы разработчикам

   RDBMS минусы:

   • Сложнее масштабировать горизонтально (требует сложное шардирование)
   • Write throughput ограничен (обычно одна машина как primary)

   NoSQL плюсы:

   • Горизонтальное масштабирование "из коробки"
   • Высокая write throughput
   • Гибкая схема

   NoSQL минусы:

   • Слабые гарантии консистентности (часто только eventual consistency)
   • Более сложные запросы (нет JOIN'ов)
   • Требует бизнес-логики на уровне приложения

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

   • RDBMS: если данные сильно связаны (relational model), нужна ACID консистентность, query patterns известны заранее
   • NoSQL: если нужна высокая write throughput, данные слабо связаны, приемлема eventual consistency

   Пример из интервью: "Для истории сообщений, где порядок и гарантии важны, я выберу PostgreSQL с read replicas. Для feed cache (часто читаемые посты пользователя), где eventual consistency OK, выберу Cassandra или Redis."

2. REST vs gRPC vs GraphQL

   REST плюсы:

   • Простой, стандартный протокол
   • Хорошо кешируется (HTTP-уровень кеширования)
   • Легко тестировать браузером

   REST минусы:

   • Overhead HTTP header'ов
   • Over/under fetching (клиент получает больше данных, чем нужно, или нужно делать несколько запросов)

   gRPC плюсы:

   • Бинарный формат (меньше payload)
   • Multiplexing (несколько запросов в одном connection)
   • Streaming встроен

   gRPC минусы:

   • Требует специального клиента и инструментов
   • Сложнее с браузером
   • Не кешируется стандартно

   GraphQL плюсы:

   • Клиент запрашивает ровно те данные, что нужны (no over/under fetching)
   • Один endpoint вместо множества REST'а

   GraphQL минусы:

   • Сложнее реализовать на backend
   • Может быть медленнее из-за сложных запросов
   • Кеширование более сложное

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

   • REST: для public API'ов, веб-клиентов, когда простота критична
   • gRPC: для микросервисной коммуникации, когда throughput важен
   • GraphQL: для клиентов с разнородными требованиями к данным (веб, мобильные приложения с разными экранами)

3. Synchronous vs Asynchronous processing

   Synchronous плюсы:

   • Простой для понимания и отладки
   • Источник истины понятен (response от сервера это всё, что нужно знать)

   Synchronous минусы:

   • Если downstream сервис медленный, весь путь медленный
   • Нужно ждать ответа перед тем, как двигаться дальше

   Asynchronous плюсы:

   • Decoupling: если один сервис упал, другие могут работать
   • Масштабирование: можно добавить workers'ов для обработки очереди
   • Better latency для пользователя (быстрый ответ, обработка в background)

   Asynchronous минусы:

   • Сложнее отладить
   • Eventual consistency: данные обновляются не сразу
   • Нужна гарантия доставки (может быть дублирование)

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

   • Synchronous: для операций, где latency критичен и нужен мгновенный результат (например, получить данные пользователя)
   • Asynchronous: для операций, где результат не нужен сразу (например, отправить email, обработать изображение, обновить статистику)

4. Single Master vs Multi Master Replication

   Single Master (Primary-Replica) плюсы:

   • Нет конфликтов при записи
   • Простая консистентность (все пишут в один primary)

   Single Master минусы:

   • Primary это bottleneck для writes
   • Failover требует выбрать новый primary (может быть сложно)

   Multi Master плюсы:

   • Разные регионы могут писать независимо
   • Лучше availability (если один master упал, другой может работать)

   Multi Master минусы:

   • Конфликты при одновременной записи (требует разрешения)
   • Сложнее консистентность

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

   • Single Master: для большинства систем, когда можно жить с тем, что все пишут в один primary
   • Multi Master: для geo-distributed систем, где каждый регион хочет писать локально без latency до главного центра

5. Strong Consistency vs Eventual Consistency

   Strong Consistency плюсы:

   • Все читают одну версию данных
   • Нет surprises

   Strong Consistency минусы:

   • Медленнее (нужно координировать reads/writes)
   • Сложнее масштабировать (нужно синхронизировать все реплики)
   • Если network partition, система не может работать (CAP theorem)

   Eventual Consistency плюсы:

   • Быстрее (можно читать из любой реплики)
   • Легче масштабировать
   • Система продолжает работать даже при сетевых сбоях (partition tolerance)

   Eventual Consistency минусы:

   • Краткосрочное рассогласование данных (user видит старые данные)
   • Требует понимания бизнес-логики и толерантности к временным несогласованностям

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

   • Strong: для критичных данных (платежи, балансы аккаунтов)
   • Eventual: для данных, где небольшая задержка OK (feed timeline, лайки на пост)

Как проговаривать trade-off'ы вслух:

"Я выбираю PostgreSQL вместо NoSQL потому, что у нас есть сложные связи между данными и нужна ACID консистентность. Недостаток: write throughput будет ограничен одним primary сервером. Для решения этого, я добавлю read replicas для distribution чтения и рассмотрю sharding при дальнейшем росте. Это добавит complexity, но позволит системе расти."

Масштабирование, устойчивость, отказоустойчивость

Масштабирование по чтению:

• Replicas: если много операций читают из БД, добавьте несколько read replicas (копии основной БД). Все пишут в primary, читают из replicas. Lag (задержка репликации) обычно в миллисекунды.
• Cache layer: выносит часто читаемые данные в Redis/Memcached. Очень быстро, но требует инвалидации кеша при обновлении.
• Secondary indices в ElasticSearch: если нужен быстрый поиск по определённым полям.
• Пример: "Для ленты новостей я буду кешировать 1000 топовых постов в Redis. Когда пользователь открывает ленту, 99% запросов попадают в Redis (2 ms latency), 1% идёт в БД."

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

• Message Queue / Broker: не пишите сразу в БД, сначала добавьте в очередь (Kafka, RabbitMQ). Workers обрабатывают очередь и пишут в БД. Это decouples производителя и потребителя.
• Batch writes: вместо записи каждого события отдельно, collect батч событий и запишите вместе. Это может быть в 10 раз быстрее.
• Sharding: если primary до-пишет свой лимит, разделите данные на несколько БД по ключу (например, по user_id % N shards). Каждый shard независимо масштабируется.
• Write-optimized DB: Cassandra, HBase для write-heavy операций.
• Пример: "Для логирования событий я буду использовать Kafka queue. Events идут в очередь, batch workers каждые 10 секунд пишут батч в Cassandra (которая оптимизирована на writes). Cassandra через 30 минут пишет в S3 для archiving. Это позволяет обработать 1 млн writes в секунду."

Репликация и шардирование:

Репликация (Replication) — это копирование данных на несколько машин:

• Master-Slave: один primary, многие secondaries. Все пишут в primary, читают из secondaries. Failover требует выбрать новый primary.
• Master-Master: несколько machines могут быть masters. Каждая может принимать writes. Конфликты разрешаются по правилам (last-write-wins, vector clocks, etc.). Сложнее, но более resilient.
• Quorum-based: для write используется quorum (большинство) machines, для read можно использовать меньше. Гарантирует консистентность.

Шардирование (Sharding) — это разделение данных по ключу на несколько БД:

• Range-based: данные с user_id 0-1M в shard 1, 1M-2M в shard 2, etc. Просто для понимания, но может быть skew (неравномерное распределение).
• Hash-based: hash(user_id) % N определяет shard. Более равномерно, но миграция shard'ов при добавлении новых шард'ов сложнее.
• Directory-based: отдельная сервис или таблица хранит mapping из ключа в shard. Очень гибко, но требует extra сервиса.

Пример: "Для database с 1000 таблицами user profiles и 10 TB данных я буду использовать hash-based sharding на 10 шард'ов (1 TB каждый). Каждый shard на отдельной машине. Когда data растёт, добавлю ещё один shard и перемигрирую половину данных (используя consistent hashing, только половина данных трогается)."

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

• Round-robin: requests по очереди: req1 -> server1, req2 -> server2, req3 -> server3, req4 -> server1. Просто, но не учитывает состояние server'ов.
• Least connections: отправляет request на server с наименьшим количеством активных connection'ов. Лучше, чем round-robin.
• IP hash: hash(client_ip) определяет server. Гарантирует, что один client всегда идёт на один server (хорошо для session affinity).
• Weighted: разные server'ы имеют разные веса (stronger machine может получить 2x трафика).

Отказоустойчивость (Fault Tolerance):

• Health checks: load balancer периодически проверяет, живы ли backend server'ы. Если не отвечает, исключает из пула.
• Retry logic: если запрос упал на одном server'е, попробуй на другом.
• Circuit breaker: если сервис часто падает, временно не отправляй ему запросы. Даёт ему время на восстановление.
• Graceful degradation: если database slow, показывай cached данные вместо ошибки.
• Redundancy: все критичные компоненты (БД, message broker) имеют redundant копии.

Кластеры:

• Несколько machines, работающих вместе, как одна единица. Cassandra cluster'а может иметь 100 machines, но приложение видит его как одну "базу данных".
• Кластер автоматически обрабатывает failover: если одна machine упала, другие continue работать.
• Data распределяется между machines (sharding на уровне cluster'а).

Как говорить про отказоустойчивость на уровне дизайн-интервью: "Для обеспечения 99.9% availability, я буду использовать: 1) несколько инстансов backend (min 3 для quorum), 2) primary-replica PostgreSQL с automatic failover, 3) Redis кластер на 3+ nodes, 4) health checks на load balancer'е, 5) circuit breaker на клиенте для graceful degradation. Если primary DB упадёт, slave's будет elected как новый primary (через Patroni или аналог). Если один backend сервер упадёт, load balancer исключит его и requests пойдут на остальные."

Данные, хранение, кеши и очереди на уровне концепций

Где хранить "истину" (Source of Truth):

• Source of truth это хранилище, которое является authoritative для данных. Для истории сообщений в чате, source of truth это primary БД.
• Cache не может быть source of truth, потому что может быть потеряна при перезагрузке. Cache это "view" данных из source of truth.
• Если кеш содержит устаревшие данные (старевает), нужна инвалидация кеша и refresh из БД.

Какие данные кешировать:

• Часто читаемые данные: профилю пользователя, конфиги приложения, топ-посты ленты.
• Данные, которые дорого вычисляются: результаты поиска, агрегированные метрики.
• Не кешируйте: данные, которые часто меняются (real-time курсы валют, если не OK 10-секундное отставание).

Инвалидация кеша:

• TTL-based: автоматически удаляй данные из кеша через N секунд. Просто, но могут оставаться устаревшие данные между invalidation'ом.
• Event-based: когда данные обновляются в БД, явно инвалидируй кеш (отправь сообщение в Kafka, которое обновит кеш'и). Более fresh, но нужен coordination.
• Hybrid: TTL + event-based. Используй TTL как страховка, но явно инвалидируй на событие для freshness.

Когда имеет смысл вводить брокер сообщений:

• Когда нужна асинхронная обработка: отправить email, обработать image, обновить статистику. App отправляет message в Kafka, worker'ы обрабатывают asynchronously.
• Когда нужно decouple компоненты: service A не должна знать про service B. Просто посылает message в Kafka, service B подписывается и обрабатывает.
• Когда нужна гарантия доставки и retry logic: message broker обеспечивает, что message будет доставлена хотя бы один раз.
• Когда нужна buffering: если write rate спайк, message broker буферизует и smooth'ит processing.

Пример: "Когда пользователь постит в ленту, я не хочу блокировать его на время отправки notifications всем followers. Вместо этого: 1) post идёт в primary БД (strong consistency), 2) event публикуется в Kafka, 3) worker'ы subscribed к topic'у получают event и отправляют notifications. Pост видна followers'ям в течение миллисекунд (из кеша или read replica'и), notifications отправляются в background (может быть несколько минут)."

Краткий чек-лист System Design ответа на уровне senior

Блоки, по которым обязательно пройти в ответе на уровне Senior:

1. Функциональные требования: что нужно реализовать (операции, scope, constraints на бизнес-логику).

2. Нефункциональные требования: нагрузка (DAU, RPS, data volume), SLA (availability, latency), consistency requirements, geo-distribution.

3. Back-of-the-envelope оценки: сколько машин, памяти, дискового пространства нужно. Показывает масштаб проблемы.

4. High-level архитектура: основные компоненты (API GW, backend, DB, cache, message broker) и как они связаны. Рисунок на доске или диаграмма.

5. Выбор технологий и trade-off'ы: почему выбираете PostgreSQL или NoSQL, synchronous или asynchronous, и какие минусы этого выбора.

6. Масштабирование: как масштабировать по чтению (replicas, кеши, indices), по записи (queues, batching, sharding). Как обработать 10x рост нагрузки.

7. Отказоустойчивость и reliability: redundancy, health checks, failover, circuit breakers, graceful degradation. Как система продолжает работать при failures.

8. Data consistency и durability: где source of truth, как кешировать, когда использовать eventually consistent systems. Гарантии на уровне архитектуры.

9. Observability и monitoring (optional, но ценится): как вы будете мониторить систему, что alertить (если RPS > threshold или latency > threshold).

10. Security (optional, если время): как защищаете API (authentication, rate limiting), данные (encryption in transit/at rest, PII handling).

Пример структурированного плана ответа в 6–8 шагов:

Шаг 1 (5 минут): Уточнение функциональных требований.

• Вопросы про операции, scope, constraints.
• Фиксирование границ: что в scope, что нет.

Шаг 2 (5 минут): Сбор нефункциональных требований.

• Нагрузка: DAU, RPS, data growth.
• SLA: availability, latency, consistency.
• Geo-distribution, budget constraints.

Шаг 3 (5 минут): Back-of-the-envelope оценки.

• Вычисления: сколько RPS, сколько GB/TB данных, примерно сколько machines.
• Показать примерные вычисления интервьюеру.

Шаг 4 (10 минут): High-level архитектура.

• Нарисовать основные компоненты.
• Обсудить data flow: как запрос идёт от клиента к backend к DB и обратно.
• Обсудить асинхронные операции, если есть.

Шаг 5 (8 минут): Выбор технологий и trade-off'ы.

• PostgreSQL vs NoSQL: почему выбираете одно.
• REST vs gRPC: когда использовать.
• Synchronous vs asynchronous: какие операции какие.
• Обсудить минусы выбора и как их смягчить.

Шаг 6 (8 минут): Масштабирование и data layer.

• Как масштабировать читы: replicas, cache, indices.
• Как масштабировать writes: queues, sharding.
• Как распределяются данные: sharding strategy.

Шаг 7 (5 минут): Отказоустойчивость и reliability.

• Redundancy: primary-replica, кластеры.
• Health checks и failover.
• Graceful degradation и circuit breakers.

Шаг 8 (Оставшееся время): Deep dive на интересующий интервьюера топик.

• Интервьюер может сказать: "Давай подробнее разберём, как ты будешь shardировать БД?"
• Приготовьтесь к уточняющим вопросам типа "а если нагрузка вырастет в 100 раз?" или "как ты будешь мониторить latency p99?"

На что особенно обращают внимание интервьюеры

Структурированность мышления

Интервьюеры ценят, когда кандидат не скачет между идеями, а движется по чёткой логике:

1. Сначала требования (что нужно сделать).
2. Потом ограничения (какие нагрузки, SLA).
3. Потом оценки (сколько машин, памяти нужно).
4. Потом архитектура (общие компоненты).
5. Потом детали (выбор технологий, масштабирование).

Кандидат, который прыгает ("А что если добавим Kafka? Погодите, а может Redis лучше? Нет, давайте ElasticSearch!") выглядит хаотичным, даже если идеи хорошие.

Пример хорошей структуры: "Сначала я уточню требования [список]. Потом оценю нагрузку [вычисления]. Потом предложу basic архитектуру [диаграмма]. Потом обсудим, как масштабировать [детали]. Наконец, обсудим reliability [failover, redundancy]. Давайте начнём?"

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

Интервьюеры ценят:

• Вы делаете явные допущения: "Давайте скажем, что у нас 1 млн active пользователей, каждый день 10 запросов в среднем."
• Вы делаете видимые вычисления (не мысленно, а "вслух" или на доске): "1 млн * 10 = 10 млн запросов в день, это примерно 100 RPS в среднем."
• Вы добавляете safety margin: "Пиковый час может быть 10x средний, так что примерно 1000 RPS на пиковой нагрузке."
• Вы делаете разумные допущения про размеры данных: "Каждое сообщение примерно 200 bytes, включая metadata."

Кандидаты, которые говорят "в системе будет very big data, поэтому нужны big data technologies" выглядят неподготовленными.

Умение проговаривать trade-off'ы и ограничения

Хороший кандидат знает, что идеального решения нет:

• "Я выбираю PostgreSQL, потому что нужна консистентность. Недостаток: сложнее масштабировать writes. Решение: используем read replicas для reads и message queue для bufferization writes."
• "Я использую in-memory кеш для быстрого доступа. Риск: данные могут быть потеряны при перезагрузке. Решение: кеш это просто ускоритель, true data в БД, и мы можем пересчитать из БД при необходимости."

Интервьюеры ценят, что вы видите не только плюсы, но и минусы, и думаете про mitigation strategies.

Ясность и логичность коммуникации

• Используйте ясный язык: "Я предлагаю три инстанса backend service'а, каждый слушает на localhost:8080, 8081, 8082. Load balancer'а распределяет трафик round-robin'ом между ними."
• Не используйте жаргон без пояснений: если сказали "we'll shard by user_id", то поясните: "Sharding означает, что мы разделяем данные: users 0-1M в database 1, 1M-2M в database 2, и т.д."
• Рисуйте диаграммы: не полагайтесь на слова, нарисуйте компоненты и arrows показывающие data flow.
• Проверяйте понимание интервьюера: "Это понятно? Нужно ли мне подробнее объяснить part'ы про шардирование?"

Типичные ошибки кандидатов на System Design собеседованиях и как их избежать

Ошибка 1: Сразу рисовать архитектуру без прояснения требований

Симптомы: "Вот мой design: Load Balancer -> 10 Backend Servers -> Master-Slave PostgreSQL -> Redis -> Kafka -> ElasticSearch."

Проблема: вы не знаете, какие требования, поэтому архитектура может быть неправильной или overengineered. Может быть, система должна обслуживать только 1000 RPS, и вам не нужны 10 servers. Или может быть, нужна strong consistency, и вы не должны использовать Kafka (eventual consistency).

Как избежать: начните с вопросов.

• "Давайте сначала уточним requirements. Сколько пользователей? Какие основные операции? Какой SLA?"
• Проведите 5–10 минут на уточнение требований, потом уже рисуйте.

Ошибка 2: Игнорирование нефункциональных требований и нагрузок

Симптомы: вы спроектировали архитектуру для 1000 RPS, но интервьюер говорит: "А что если у нас 1 млн RPS?" и вся архитектура разваливается.

Проблема: нефункциональные требования определяют, нужны ли вам 2 servers или 200. Если вы их проигнорировали, вся архитектура может быть не масштабируема.

Как избежать: явно обсудите нагрузку и SLA.

• "Итак, нефункциональные требования: 1 млн DAU, примерно 100 000 RPS на пиковой нагрузке, p99 latency < 500 ms, 99.9% availability, data consistency. Это верно?"
• Делайте видимые расчёты: "100 000 RPS на одном server'е (допустим, 1000 RPS per server) требует 100 server'ов. Это много, нужно optimizer: добавить кеш, sharding и т.д."

Ошибка 3: Перегрузка деталей реализации вместо фокуса на архитектуре

Симптомы: вы говорите про implementation details вместо архитектурных решений.

• "Мы будем использовать Spring Boot с @Transactional аннотацией, и это обеспечит ACID гарантии..." (это implementation detail, не архитектурное решение)
• "Мы используем Jackson для serialization JSON'а..." (тоже detail)
• "Я напишу retry logic с exponential backoff и jitter..." (implementation, не architecture)

Проблема: интервьюер проверяет System Design (architecture level), а не coding skills. Фокус на details показывает, что вы не видите big picture.

Как избежать: оставайтесь на уровне архитектуры.

• Говорите про компоненты, взаимодействие, trade-off'ы, масштабирование.
• Если интервьюер спросит про детали, ответьте кратко: "На implementation level мы используем Spring Boot с repositories, но на архитектурном уровне это просто 'Backend Service, которая читает/пишет из БД через DAL'."

Ошибка 4: Отсутствие trade-off'ов и альтернатив

Симптомы: вы выбираете решение и говорите, что это perfect choice, без обсуждения альтернатив.

• "Мы используем NoSQL, потому что это лучше, чем SQL."
• "Мы используем Kafka, потому что это самый популярный message broker."

Проблема: это показывает, что вы не глубоко знаете технологии и не можете принимать обоснованные решения. На самом деле, выбор между SQL и NoSQL зависит от requirements, и нет один "better".

Как избежать: всегда обсуждайте trade-off'ы.

• "Я рассматриваю два варианта: PostgreSQL и Cassandra. PostgreSQL даёт ACID гарантии и мощные query'ы, но сложнее масштабировать horizontally. Cassandra даёт линейное масштабирование, но слабые consistency гарантии. Учитывая requirement на strong consistency в нашем случае, я выбираю PostgreSQL."

Ошибка 5: Непоследовательный или хаотичный стиль ответа

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

• "Ой, я забыл про кеш. Давайте переделаем всю архитектуру."
• "А может использовать microservices? Нет, wait, может быть монолит лучше?"
• "Хм, я не уверен, может Redis лучше, или Memcached?"

Проблема: это показывает неуверенность и слабое понимание. Даже если идеи потом оказываются хорошими, presentation wichtig.

Как избежать: подготовьтесь и придерживайтесь плана.

• Перед ответом в голове пройдите логику: требования → нагрузки → компоненты → trade-off'ы.
• Если во время ответа понимаете, что что-то упустили, скажите чётко: "Погодите, я понял, что недостаточно обсудили масштабирование по записи. Давайте добавим message queue в архитектуру."
• Будьте уверены в выборе, даже если потом оказываются альтернативы: "Я выбираю PostgreSQL, потому что [причины]. Если бы requirements были другие, рассмотрели бы NoSQL, но сейчас PostgreSQL лучше fit."

Ошибка 6: Отсутствие обсуждения reliability и disaster recovery

Симптомы: вы спроектировали функциональную архитектуру, но когда интервьюер спрашивает "А что если primary database падёт?", вы не готовы к ответу.

Проблема: на production системы reliability это huge concern. Если primary database упадёт и у вас нет failover плана, система down'а. Хороший кандидат всегда думает про failure scenarios.

Как избежать: всегда включайте reliability в архитектуру.

• "Для reliability я использую: 1) Primary-replica PostgreSQL с automatic failover (Patroni или управляемый service), 2) health checks на load balancer'е, 3) Redis cluster на 3+ nodes, 4) регулярное бекапирование к S3."
• Подумайте про network partitions, hardware failures, bugs в code'е.

Ошибка 7: Игнорирование requirements, которые кажутся простыми

Симптомы: интервьюер говорит "А что если нам нужна full-text search на ленте?" а вы: "О, можно просто использовать LIKE в PostgreSQL."

Проблема: LIKE в PostgreSQL это O(n) операция и очень медленная на большых данных (млрд записей). Хороший кандидат сразу вспомнит ElasticSearch или другие search engines.

Как избежать: знайте, что каждый feature может иметь implications для архитектуры.

• Когда интервьюер добавляет новый requirement, спросите себя: "Как это влияет на архитектуру? Нужна ли новая компонента?"

Заключение на уровне практики

System Design это не про знание всех технологий, а про структурированный процесс думания. Хороший кандидат может спроектировать любую систему, даже если раньше с ней не работал, потому что он знает фундаментальные компоненты (backend, DB, cache, queue, search), trade-off'ы, и методологию approach'а.

На собеседовании интервьюер смотрит на:

1. Можешь ли ты задать правильные вопросы?
2. Можешь ли ты считать и оценить масштаб?
3. Знаешь ли ты, как компоненты работают и взаимодействуют?
4. Можешь ли ты обсудить trade-off'ы?
5. Думаешь ли ты про reliability и edge cases?
6. Можешь ли ты это всё ясно объяснить?

Если на все вопросы "да", ты готов к собеседованию.

System Design: Сбор требований, расчет нагрузки

Роль сбора требований и capacity planning в System Design

Без чётких требований и понимания нагрузок проектирование архитектуры бессмысленно: неправильные базы, неподходящие паттерны, неработающая система в проде. Вся система строится под реальные потребности, сценарии и предсказуемые нагрузки.

В продуктовой разработке грамотный system design всегда начинается с разбора, «что именно и для кого нужно реализовать», как и сколько этим будут пользоваться, какие SLA требуются бизнесу.

На собеседовании любой опытный интервьюер начинает разбор с вопросов: «Какой функционал?», «Сколько пользователей?», «Какие требования по производительности?» — ожидая, что кандидат сам инициирует уточнение.

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

Функциональные требования — это описания основных сценариев использования системы: кто, что и с какими ограничениями делает.

Роли и сценарии бывают следующими:

• Пользовательская роль ("User", "Admin", "Moderator").
• Действия (создать заказ, оплатить, отправить сообщение).
• Ограничения (например, пользователь может отправить до 10 сообщений в минуту).

Чёткая формулировка:

• «Система позволяет зарегистрированному пользователю создавать и удалять свои записи, админ — просматривать все записи».
• «Каждый заказ можно оплатить онлайн или через курьера».

Границы системы:

• Важно обозначить, что именно включено в зону проектирования (core сервисы) и что выступает внешними системами (платёжные шлюзы, сторонние API, фронтенд).

Типовые вопросы, чтобы не пропустить сценарии:

• «Какие основные действия может выполнить пользователь?»
• «Есть ли ограничения на частоту запросов?»
• «Какой минимальный и максимальный объём данных в одном действии?»
• «Какие внешние системы должны быть интегрированы?»

Не стоит погружаться в подробности бизнес-логики до уровня полей и формул — задачи архитектуры требуют макроуровня и понимания потоков данных.

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

Нефункциональные требования (NFR) — это параметры качества работы системы, не связанные с функциональностью, но определяющие требования к инфраструктуре и архитектуре:

• Производительность: задержки (latency, например, 100 мс P99), пропускная способность (throughput, например, 1000 RPS).
• Доступность: можно ли получить доступ к сервису (например, 99.99% Uptime).
• Надёжность: сохранность данных при сбоях, отсутствие потерь.
• Долговечность: гарантии хранения данных (например, сообщение не теряется 5 лет).
• Консистентность: насколько данные мгновенно и согласованно обновляются.
• Масштабируемость: возможность работы и увеличения нагрузки.
• Безопасность: аутентификация, авторизация, хранение паролей.
• Геораспределённость: наличие пользователей и данных в нескольких регионах.

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

• SLI (Service Level Indicator) — конкретная метрика качества ("средняя задержка ответа = 150 мс").
• SLO (Service Level Objective) — целевое значение ("P95 latency < 200 мс").
• SLA (Service Level Agreement) — договорное обязательство ("Гарантируем 99.9% аптайм, штраф при нарушении").

Чёткие численные цели нужны всегда. Формулируем требования правильно:

• Вместо «быстро» — «latency 100 мс P99».
• Вместо «надёжно» — «данные не теряются ни при каких сбоях».
• Вместо «много пользователей» — «пиковая нагрузка 5000 RPS, 1 млн MAU».

Основные метрики нагрузки

• RPS/QPS (requests/queries per second): количество входящих/исходящих запросов и операций в секунду.
  • Например, «API должен обрабатывать 1000 RPS».
• DAU/MAU (Daily/Monthly Active Users): активные уникальные пользователи в день/месяц.
• Одновременно онлайн: максимальное количество единовременно активных пользователей — критично для расчёта конкурентных соединений.
• Частота действий на пользователя: сколько действий делает пользователь в минуту, час, день.
• Read/write ratio: отношение числа чтений к записям (например, 80% read, 20% write).
• Размер запроса/ответа: средний объем данных per request (например, 2 КБ).
• Профиль нагрузки: когда случаются пики (часы, дни, сезоны), особенности паттернов активности.

Базовый алгоритм оценки нагрузки (back-of-the-envelope вычисления)

1. Оценка аудитории
   • Сколько MAU? Сколько DAU? Сколько одновременно онлайн?
   • «Зададим допущение: в месяц 120 тыс. MAU, в день 10 тыс. DAU, одновременных — до 1000».
2. Оценка активности
   • Сколько действий/запросов делает средний пользователь?
   • «В среднем 10 запросов в день, в пике (например, в эвент) — 100».
3. Расчёт RPS
   • RPS средний: DAU * среднее число запросов в сутки / 86400.
   • Пиковый RPS: учитываем пиковые интервалы активности.
   • «1000 пользователей x 5 запросов за 1 минуту = 83 RPS (в течение пика)».
4. Оценка распределения нагрузки между компонентами
   • Gateway, backend, Database, Cache — сколько запросов каждой компоненте.
   • «Из 1000 входящих RPS: 800 идут в кеш, 200 — напрямую в БД».
5. Оценка объёма хранения
   • Размер одной сущности: «Запись — 2 КБ данных».
   • Сколько сущностей в день: «100 тыс. новых сообщений ежедневно».
   • Объём данных: «100 тыс. x 2 КБ = 200 МБ в день, 6 ГБ в месяц».
   • Рост: «Через год — 72 ГБ новых».
   • Архивирование, TTL: «Старые данные архивируем через 12 месяцев».
6. Оценка сетевого трафика
   • In/out: «1000 RPS x 2 КБ = 2 МБ/c входящего / исходящего трафика».

Примеры:

• "Допустим, 10 000 DAU, каждый делает 20 запросов в среднем — это 200 000 запросов/день, что в среднем 2,3 RPS; в пик (10% DAU, 50 действий за час) — до ~14 RPS".
• "Храним по 4 КБ/запись, приход новых = 20 000 * 4 КБ = 80 МБ/сутки данных".

Capacity planning для ключевых компонентов

Веб- и API-сервера

• RPS делим на пропускную способность одного инстанса: «Если одна Java-инстанция обрабатывает 100 RPS, при нагрузке 800 RPS нужно минимум 8 инстансов плюс запас».
• Latency: какой допустим (см. SLO).
• Timeouts: устанавливаем грамотные границы отклика.
• Connection pools: размер connection pool вычисляется из числа конкурентных соединений, p95-p99 задержек.

Базы данных

• Количество запросов в БД на пользовательский запрос: «Каждый API-запрос — 2 чтения (User, Product), одна запись (Order)».
• RPS для БД = API RPS * среднее число операций на запрос.
• Предел одного инстанса: знание физического лимита (например, «PostgreSQL максимум 2000 QPS на c5.xlarge, дальше рост latency»).
• Порог для репликации — когда чтения начинают доминировать.
• Шардирование: при превышении объёмов или write QPS, когда RDS не масштабируется вертикально.

Кеши

• Cache hit ratio — доля попаданий: «Если 80% запросов идёт в кеш, на БД попадает только 20% нагрузки».
• Пример: было 1000 RPS, с кешем 0.8 hit-ratio — на storage попадает только 200 RPS.
• Экономия на latency, разгрузка базы.

Очереди и брокеры сообщений

• Оцениваем объём сообщений (msg/sec, MB/sec).
• Скорость потребления: «Очередь Kafka способна принимать 5000 сообщений в секунду, каждая consumer group потребляет 1000 msg/sec».
• Burst-нагрузки: очереди позволяют сгладить пики (выравнивание backlog), обработка в off-peak.

Работа с пиками и запас по мощности

• Average vs Peak load: средние нагрузки всегда ниже пиковых. Дизайн обязателен под peak, иначе будут проблемы в highload.

• Safety margin (коэффициент запаса): обычно 20–30% сверх оценки для непредвиденных всплесков.

• Burst traffic, flash crowd, акции — увеличиваем запас к пиковым значениям.

• Стратегии против пиков:

  • Autoscaling: автоматическое масштабирование инстансов по метрикам.
  • Rate limiting: ограничение числа запросов с одного пользователя / IP.
  • Очереди: буферизация входящего потока, асинхронная обработка.

Как презентовать вычисления на собеседовании

• Проговаривать вслух все допущения: «Буду считать средний размер entity 2 КБ...»
• Если нет точных данных — выбирать разумные "по умолчанию" (например, RPS для табличного CRUD — десятки/сотни).
• Демонстрировать ход рассуждений: «Если API будет обслуживать 1000 DAU и на пике — до 100 одновременно онлайн, это значит concurrency...»
• Аргументировать порядок цифр, а не абсолютное значение — этого достаточно интервьюеру.
• Баланс: скорость и логика ценятся выше, чем абсолютная точность.

Capacity planning и выбор архитектурных решений

Знание нагрузок позволяет обосновать структуру архитектуры:

• RDBMS vs NoSQL: при write-heavy и большом DAU — NoSQL, для транзакционного consistency — RDBMS.
• Горизонтальное vs вертикальное масштабирование: увеличение количества инстансов против мощности одной машины.
• Синхронное vs асинхронное взаимодействие: задержки и возможности работы "в фоне" для разгрузки.
• Кеширование vs работа напрямую с БД: кеш для пиков/горячих данных, "холодная" база — только для уточняющих операций.

Пример эволюции:

• Система для 1 000 пользователей — достаточно одной реплики RDBMS, без кеша.
• При росте до 1 млн: появляются кеш, read-реплики, очереди, NoSQL для части данных, асинхронные воркеры.

Краткий чек-лист по сбору требований и оценке нагрузки

Кандидат всегда уточняет:

• Для кого система (роли, типы пользователей)?
• Какой базовый функционал нужен?
• Какие сценарии — создание, обновление, просмотр, удаление?
• Какие интеграции с внешними системами?
• Какой объём активных пользователей (MAU, DAU, online)?
• Сколько действий/запросов в сутки/час/секунду?
• Какой профиль нагрузки? Какие пики?
• Какие SLA/SLO по latency, availability, durability?
• Какой размер сущностей/запросов?
• Какой объём хранимых данных? Какой рост?
• Есть ли требования по консистентности, безопасности?
• География пользователей (один регион или весь мир)?

Алгоритм:

1. Кто пользователи?
2. Что делают?
3. Как часто?
4. Сколько одновременных действий?
5. Какие есть ограничения и бизнес-правила?
6. Какой ожидаемый объём данных?
7. Какие критические NFR?
8. Где и когда будут пики?

Эти вопросы надо озвучивать в начале обсуждения design-задачи, вплетая их в структуру ответа.

Типичные ошибки при сборе требований и оценке нагрузки

• Полное игнорирование нефункциональных требований (вся фокусировка на сценариях).

• Отсутствие численных оценок: «много пользователей», «высокая нагрузка» без цифр.

• Приведение случайных, неоснованных на бизнесе или данных цифр.

• Несогласованность: суммы не сходятся, RPS не совпадает с DAU/MAU.

• Уход в детали на уровне кода до выяснения ключевых параметров.

• Как избежать:

  • Всегда уточнять и озвучивать допущения («буду считать, что 10 000 DAU, пиковая нагрузка — 100 RPS»).
  • Быстро оценивать порядок величин, не детализацию.
  • Все NFR должны быть названы и озвучены архитектурные trade-off'ы.
  • Все цифры должны увязываться между собой и с логикой бизнеса.

System Design: архитектурные стили и паттерны для микросервисов, монолитов и event-driven систем на собеседованиях senior-разработчиков.

Зачем понимать архитектурные стили на System Design собеседовании

На интервью архитектурный стиль — это не академический выбор, а осознанное решение, которое влияет на всю траекторию разработки системы. Интервьюер оценивает, насколько кандидат понимает trade-off'ы между разными подходами и может ли обосновать выбор на основе требований.

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

Архитектурный стиль определяет:

• Масштабируемость: микросервисы позволяют масштабировать отдельные компоненты, монолит часто требует горизонтального масштабирования всего приложения.
• Скорость разработки: модульный монолит быстрый на старте, но может замедлить развитие при росте сложности; микросервисы добавляют overhead, но дают свободу отдельным командам.
• Отказоустойчивость: event-driven системы с асинхронной обработкой обычно более устойчивы к сбоям отдельных компонентов, чем синхронные монолиты.
• Модель данных: выбор между единой БД (монолит) и распределённым хранилищем (микросервисы) принципиально меняет подход к транзакциям и консистентности.
• Операционная сложность: микросервисы требуют Kubernetes, логирования, трейсинга; монолит проще в эксплуатации, но может стать неуправляемым при росте.

Что хочет увидеть интервьюер

Интервьюер ищет кандидата, который:

• Не выбирает паттерн "по тренду", а обосновывает решение требованиями (нагрузка, команда, временные горизонты).
• Осознаёт trade-off'ы: "микросервисы дают параллельное развитие, но усложняют отладку и сетевые взаимодействия".
• Показывает, что кодил на этих стилях: приводит примеры из реальных проектов (Spring Boot приложение с Kafka, Event Sourcing в Kafka, CQRS с отдельной read-моделью).
• Может эволюционировать архитектуру: начал с монолита, вырос в модульный монолит, потом выделил микросервисы.
• Обсуждает не только код, но и операционный контекст: CI/CD, мониторинг, disaster recovery.

Связь стилей с реальным опытом Java/Spring-разработчика

Типичный путь опытного backend-разработчика на Java:

1. Классический Spring Boot монолит: @SpringBootApplication, однослойная или трёхслойная архитектура (controller → service → repository).
2. Рост в модульный монолит: выделение bounded context-ов как пакетов или модулей Spring, использование spring-context, явные контракты между модулями.
3. Переход на микросервисы: Spring Cloud, отдельные Spring Boot приложения, spring-cloud-gateway для API gateway, spring-kafka для async взаимодействия.
4. Углубление в event-driven: spring-kafka, spring-cloud-stream, domain events, integration events, event sourcing с Apache Kafka или другим хранилищем событий.
5. CQRS и проекции: в read-модели используются оптимизированные запросы, например, Elasticsearch или отдельная БД для аналитики.

На интервью важно показать, что ты понимаешь эту эволюцию не как набор фич, а как логичные ответы на растущие требования.

Обзор основных архитектурных стилей

Монолит

Определение: одно развёрнутое приложение, содержащее всю бизнес-логику и совместное использование одной модели данных, обычно одной базы данных.

Структура монолита

User Interface (Presentation)
  ↓
API Controllers (Spring @RestController)
  ↓
Services (бизнес-логика, Spring @Service)
  ↓
Repositories (доступ к БД, Spring @Repository)
  ↓
Single Database (PostgreSQL, MySQL)

Плюсы монолита

• Простота деплоя: один jar/war файл, одна команда развёртывания (или Docker контейнер).
• Целостная модель данных: транзакции ACID на уровне всего приложения, без распределённых транзакций и двухфазных коммитов.
• Простота разработки на старте: не нужно думать про API контракты между сервисами, о сетевых сбоях, о синхронизации между компонентами.
• Производительность: вызовы между компонентами — в памяти процесса, не через сеть, latency ~ микросекунды.
• Лёгкая отладка: весь стек в одном процессе, breakpoint-ы и логирование работают прямолинейно.

Минусы монолита

• Затруднённое масштабирование по отдельным компонентам: если нужна высокая пропускная способность для чтения продуктов, приходится масштабировать весь монолит, включая код авторизации, платежей и т.д.
• Сложность изменений в больших кодовых базах: при росте монолита до миллионов строк кода усложняется добавление новых фич, возрастает риск побочных эффектов.
• Технологический lock-in: если монолит написан на Java, сложно добавить компонент на Go или Python без больших архитектурных изменений.
• Нарушение принципа единственной ответственности: со временем в монолите появляются слабо связанные модули (пользователи, заказы, платежи, рекомендации), которые мешают друг другу.
• Сложность команд: трудно дать отдельной команде полное владение одной фичей без координации с другими.

Когда монолит — разумный выбор

• Стартап или MVP: нужно быстро проверить идею, монолит позволит это сделать за недели.
• Небольшая система: несколько сервисов (авторизация, каталог товаров, корзина), команда из 5–10 человек.
• Требования к консистентности строгие: финансовые расчёты, где нужна ACID, микросервисы усложнят жизнь.
• Операционный контекст простой: нет опыта с Kubernetes и распределёнными системами, нужна система, которую может поддерживать небольшая операционная команда.
• Нет требования к технологическому многообразию: все компоненты системы хорошо реализуются на Java/Spring.

Модульный монолит

Определение: монолит, разделённый на явные, автономные модули (bounded context-ы), каждый с чёткой границей ответственности и внутренним контрактом. Это не просто пакеты в одном приложении, а явно спроектированная структура с минимальными перекрёстными зависимостями.

Отличие от "анемичного" монолита

Анемичный монолит — это когда одно приложение, но нет явных граней между компонентами:

// Анемичный монолит: OrderService зависит от UserService, 
// UserService от PaymentService, всё перепутано
@Service
public class OrderService {
    @Autowired private UserService userService;
    @Autowired private PaymentService paymentService;
    @Autowired private NotificationService notificationService;
    
    // Сложные зависимости, трудно изменять отдельные части
}

Модульный монолит — это когда чётко определены границы:

monolith-app/
├── user-module/
│   ├── domain/
│   │   └── User, UserRepository (интерфейс)
│   ├── application/
│   │   └── UserService
│   ├── api/
│   │   └── UserController
│   └── infrastructure/
│       └── UserRepositoryImpl (реализация)
├── order-module/
│   ├── domain/
│   │   └── Order, OrderRepository (интерфейс)
│   ├── application/
│   │   └── OrderService
│   ├── api/
│   │   └── OrderController
│   └── infrastructure/
│       └── OrderRepositoryImpl
└── shared/
    └── EventPublisher, UserDTO (для inter-module общения)

Явные границы модулей и внутренние контракты

В модульном монолите:

• Каждый модуль имеет чётко определённый API: обычно это набор интерфейсов в пакете application или api, которые открыты для других модулей.
• Зависимости между модулями идут только в одну сторону: например, order-module может зависеть от user-module, но не наоборот. Это предотвращает циклические зависимости.
• Прямое обращение к domain-классам другого модуля запрещено: модули общаются через DTO или event-ы, не передавая domain-сущности.
• Каждый модуль может иметь свою БД (хотя на деле часто одна общая БД с раздельными таблицами/схемами): это подготавливает к возможному переходу на микросервисы.

Примеры организации в Java/Spring

Spring Modulith (относительно новый проект Spring) помогает организовать модули:

// В одном приложении несколько модулей
// spring-modulith автоматически проверяет зависимости между модулями

// user-module
package com.example.shop.user;
public class User { ... }

// order-module
package com.example.shop.order;
@Service
public class OrderService {
    private final UserService userService; // Допустимо: явная зависимость
    // ...
}

// payment-module
package com.example.shop.payment;
@Service
public class PaymentService {
    // Не может зависеть от order-module, чтобы избежать цикла
}

Bounded context — концепция из Domain-Driven Design:

• Order-module представляет bounded context заказов с собственной моделью (Order, OrderLine, OrderStatus).
• User-module представляет bounded context пользователей с собственной моделью (User, Profile, Preferences).
• Они общаются через чётко определённые API и события, не деля внутренние классы.

Независимое развитие модулей

В модульном монолите команда может:

• Изменять внутреннюю реализацию Order-service (например, перейти на другую БД для заказов), не трогая остальной код.
• Разрабатывать новые фичи в User-module параллельно с разработкой в Order-module, если они касаются разных bounded context-ов.
• Нанять отдельного разработчика на Payment-module, зная, что он не будет случайно нарушать инварианты Order-module.

Когда модульный монолит эффективнее микросервисов

• Ранние стадии роста: система выросла за пределы простого монолита (50–100 тыс. строк кода), но ещё не требует полной развёртки микросервисов.
• Нет необходимости в независимом масштабировании: если все модули имеют примерно одинаковую нагрузку.
• Основная команда одна: нет отдельных команд, которым нужна полная автономия по развёртыванию.
• Требования к согласованности высоки: модульный монолит даёт транзакции ACID, которые трудно обеспечить в микросервисах.
• Операционная простота: нет нужды в Kubernetes, Service Discovery, распределённом трейсинге с самого начала.

Микросервисы

Определение: архитектурный стиль, где система разбита на набор независимых сервисов, каждый с собственной БД, собственным процессом развёртывания, взаимодействующих через API (REST, gRPC) и/или асинхронные каналы (Kafka, RabbitMQ).

Ключевые признаки микросервисов

• Раздельное хранилище данных: каждый микросервис отвечает за свою БД, нет общего хранилища.
• Независимый деплой: изменение в Order-service не требует пересборки и переразворачивания User-service.
• Технологическая независимость: Order-service может быть на Java/Spring, а Payment-service на Go или Node.js.
• Раздельная scalability: Order-service можно масштабировать до 100 инстансов, в то время как User-service остаётся с 5.

Плюсы микросервисов

• Независимое масштабирование: каждый сервис может быть масштабирован отдельно под свою нагрузку.
• Технология-агностика: разные микросервисы могут использовать разные языки, БД, фреймворки в зависимости от требований.
• Организационное разделение: каждой команде можно дать в полное владение один или два микросервиса (принцип "two-pizza team" в Amazon).
• Гибкость разработки: команда может обновлять свой микросервис с собственной скоростью, не дожидаясь других.
• Изоляция сбоев: если платёжный сервис падает, заказы могут ставиться в очередь и обрабатываться позже.

Минусы микросервисов

• Сложность инфраструктуры: нужна orchestration платформа (Kubernetes), API Gateway, Service Discovery, Circuit Breaker, Distributed Tracing.
• Распределённые транзакции: вместо ACID в одной БД, нужно использовать saga-паттерны (orchestration или choreography), что усложняет логику и требует компенсирующих транзакций.
• Observability: логирование, метрики, трейсинг распределены между сервисами, требуется централизованное решение (ELK, Jaeger, Prometheus).
• Сетевые сбои: вызовы между сервисами идут по сети, может быть задержка, таймауты, потеря пакетов. Нужны retry-логика, timeout-ы, fallback-и.
• Увеличенная latency: вместо вызова функции в памяти (наносекунды), нужен HTTP/gRPC вызов (миллисекунды).
• Сложность локальной разработки: вместо одного docker-compose up, нужно поднять десяток контейнеров с зависимостями, синхронизировать версии API.

Типичные анти-паттерны

• Микросервисы "по таблицам": каждая таблица БД — отдельный микросервис (User-service, Order-service, OrderLine-service). Это приводит к распределённым транзакциям и рассеиванию бизнес-логики.
• Слишком мелкие сервисы: сервис-агрегатор заказа вызывает Service1 → Service2 → Service3 → Service4 → Service5, и одна пользовательская операция требует 5 сетевых вызовов.
• Неправильное разбиение по bounded context: Order-service зависит от User-service, User-service от Product-service, Product-service от Order-service (циклические зависимости).
• Попытка использовать одну общую БД вместо раздельных: тогда это не микросервисы, а просто несколько приложений с анемичными сервисами.

Правильное разбиение на микросервисы

Правильное разбиение следует bounded context-ам из Domain-Driven Design:

• User Context: управление профилем, авторизацией, настройками.
• Product Context: каталог товаров, описания, изображения.
• Order Context: создание заказов, управление статусами.
• Payment Context: обработка платежей, интеграция с платёжными системами.
• Notification Context: отправка email, SMS, push-уведомлений.

Каждый context имеет собственное представление сущностей (например, User в Payment-context — это только ID и платёжные реквизиты, а не весь профиль).

SOA, Serverless: краткий обзор

Service-Oriented Architecture (SOA)

Определение: архитектурный стиль, где система состоит из набора сервисов, предоставляющих бизнес-функции через чётко определённые интерфейсы (обычно SOAP/XML на рассвете SOA).

Отличие от микросервисов: SOA часто использует централизованную интеграционную шину (ESB — Enterprise Service Bus), в то время как микросервисы обычно предпочитают decentralized approaches (каждый сервис отвечает за свою интеграцию). SOA может быть более "монолитной" в плане управления, микросервисы — более автономные.

Для интервью: упомяни, что SOA — это предшественник микросервисов, и микросервисы — это более современный, лёгкий вариант SOA с меньшим overhead на интеграционную инфраструктуру.

Serverless

Определение: модель, где разработчик пишет функции (Lambda на AWS, Cloud Functions на GCP), а облачный провайдер управляет инфраструктурой, масштабированием и выставляет счёт за реальное использование.

Связь с микросервисами: serverless часто используется как дополнение к микросервисам. Например:

• Асинхронная обработка событий через AWS Lambda + SNS/SQS.
• Преобразование данных (ETL) через Cloud Functions.
• Webhook-обработчики для внешних сервисов.

Для интервью: упомяни, что serverless удобен для I/O-bound операций и event-driven обработки, но может быть дороговат для long-running задач или CPU-heavy workloads. На System Design собеседовании serverless часто используется как часть решения, а не как основной архитектурный стиль (за исключением специальных кейсов).

Слоистая (Layered) архитектура

Определение: архитектурный стиль, где приложение разделено на горизонтальные слои, каждый с чётко определённой ответственностью. Это, вероятно, самый распространённый паттерн в Spring Boot приложениях.

Основные слои

1. Presentation Layer (API Layer)

Ответственность: приём HTTP-запросов, валидация входных данных, преобразование запросов в формат, понятный для application layer.

В Java/Spring: @RestController, @PostMapping, @GetMapping, обработка параметров, маршрутизация.

@RestController
@RequestMapping("/orders")
public class OrderController {
    @PostMapping
    public ResponseEntity<OrderDTO> createOrder(@RequestBody CreateOrderRequest request) {
        // Валидация на уровне контроллера
        Order order = orderService.createOrder(request.getUserId(), request.getItems());
        return ResponseEntity.ok(convertToDTO(order));
    }
}

2. Application/Service Layer

Ответственность: бизнес-логика, координация операций, управление транзакциями. Не содержит вызовы к БД, это делает infrastructure layer.

В Java/Spring: @Service, методы с @Transactional, вызовы repositories.

@Service
@Transactional
public class OrderService {
    private final OrderRepository orderRepository;
    private final UserRepository userRepository;
    
    public Order createOrder(Long userId, List<OrderItemDTO> items) {
        User user = userRepository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException());
        Order order = new Order(user, items);
        // Логика проверки, расчётов и т.д.
        return orderRepository.save(order);
    }
}

3. Domain Layer

Ответственность: доменные сущности, бизнес-правила, которые не зависят от фреймворков и технологий. Не содержит Spring аннотации, это чистый бизнес-код.

В Java/Spring: POJO (Plain Old Java Object) классы, методы, которые реализуют бизнес-логику.

public class Order {
    private Long id;
    private User user;
    private List<OrderItem> items;
    private OrderStatus status;
    
    public Order(User user, List<OrderItem> items) {
        this.user = user;
        this.items = items;
        this.status = OrderStatus.PENDING;
    }
    
    public BigDecimal calculateTotal() {
        return items.stream()
            .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
            .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
    
    public void confirm() {
        if (this.status != OrderStatus.PENDING) {
            throw new IllegalStateException("Can only confirm pending orders");
        }
        this.status = OrderStatus.CONFIRMED;
    }
}

4. Infrastructure Layer

Ответственность: доступ к БД, внешним сервисам, файловой системе, кешу. Реализует интерфейсы, определённые в service layer.

В Java/Spring: @Repository, JPA entities, реализация custom запросов, взаимодействие с Kafka, Redis и т.д.

@Repository
public interface OrderRepository extends JpaRepository<OrderEntity, Long> {
    List<OrderEntity> findByUserId(Long userId);
    // Custom запросы для специфичных случаев
}

@Service
public class OrderNotificationService {
    @Autowired
    private KafkaTemplate<String, OrderEvent> kafkaTemplate;
    
    public void publishOrderCreated(Order order) {
        kafkaTemplate.send("orders.created", new OrderCreatedEvent(order.getId()));
    }
}

Горизонтальные зависимости: кто может зависеть от кого

Правило: зависимости идут только в одну сторону, сверху вниз:

Presentation Layer
        ↓
Application/Service Layer
        ↓
Domain Layer
        ↓
Infrastructure Layer

• Presentation Layer зависит от Application Layer (контроллер вызывает сервис).
• Application Layer зависит от Domain Layer (сервис работает с доменными объектами) и Infrastructure Layer (сервис вызывает repositories).
• Domain Layer не зависит ни от кого (POJO, чистая бизнес-логика).
• Infrastructure Layer зависит от Domain Layer (repository работает с доменными объектами).

Обратные зависимости запрещены: Infrastructure Layer не должна вызывать Application Layer (это приводит к циклам и нарушает слоистость).

Типичные нарушения слоистости и их последствия

Нарушение 1: Logic в Presentation Layer

// ❌ ПЛОХО: бизнес-логика в контроллере
@RestController
public class OrderController {
    @PostMapping("/orders")
    public ResponseEntity<OrderDTO> createOrder(@RequestBody CreateOrderRequest request) {
        // Здесь не должно быть бизнес-логики!
        BigDecimal total = request.getItems().stream()
            .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
            .reduce(BigDecimal.ZERO, BigDecimal::add);
        
        if (total < BigDecimal.ZERO) {
            return ResponseEntity.badRequest().build();
        }
        // ...
    }
}

Последствия: трудно тестировать логику отдельно (нужен mock HTTP), сложно переиспользовать эту логику в других контроллерах (например, для gRPC endpoint-а), нарушается разделение ответственности.

Нарушение 2: Прямой доступ из Infrastructure к Presentation

// ❌ ПЛОХО: repository вызывает контроллер
@Repository
public class OrderRepositoryImpl {
    @Autowired
    private OrderController orderController; // ЦИКЛИЧЕСКАЯ ЗАВИСИМОСТЬ!
    
    public Order save(Order order) {
        // ...
        orderController.notifyUser(order); // Неправильно!
        return order;
    }
}

Последствия: циклические зависимости, невозможно тестировать repository отдельно, нарушение зоны ответственности.

Нарушение 3: Утечка инфраструктурных деталей в Domain

// ❌ ПЛОХО: доменная сущность зависит от Spring
@Entity // Spring/JPA аннотация в domain-классе!
@Table(name = "orders")
public class Order {
    @Id
    private Long id;
    @OneToMany
    private List<OrderItem> items;
}

Последствия: domain layer становится зависим от JPA, сложнее тестировать, нарушается чистота доменной модели, трудно менять БД (например, с JPA на MongoDB).

Пример: как описать layered architecture на System Design собеседовании

Кандидат проговаривает:

Я предлагаю слоистую архитектуру. Со стороны клиента приходят REST запросы в Presentation layer, где мы валидируем входные данные и преобразуем их. Затем запрос идёт в Application layer — это Spring Service, где размещена основная бизнес-логика: расчёты, проверки инвариантов, координация с другими сервисами. Service работает с чистыми доменными объектами — это Order, User, Payment. И наконец, Infrastructure layer — это repositories, которые маппят доменные объекты в БД.

Зависимости идут только в одну сторону, снизу вверх: Presentation → Service → Domain ← Infrastructure. Это позволяет легко тестировать бизнес-логику без Spring контекста, легко менять реализацию (например, БД), и обеспечивает чистоту кода.

Hexagonal Architecture (Ports and Adapters)

Определение: архитектурный стиль, где доменная логика расположена в центре (core), а взаимодействие с внешним миром (БД, API, queue-и) осуществляется через порты (интерфейсы) и адаптеры (реализации). Также известна как "Ports and Adapters" архитектура.

Концепция: порты и адаптеры

Порты

Портом называется интерфейс, который определяет, как domain layer хочет взаимодействовать с внешним миром.

Типы портов:

1. Входящий порт (Inbound Port): это интерфейс, через который внешний мир вызывает бизнес-логику. Обычно это use case или application service.

// Входящий порт: как внешнее приложение или контроллер вызывает core logic
public interface CreateOrderUseCase {
    OrderResponse execute(CreateOrderRequest request);
}

2. Исходящий порт (Outbound Port): это интерфейс, через который domain layer зависит от внешних сервисов (БД, платёжные системы, уведомления).

// Исходящий порт: как domain layer хочет сохранять заказы (не важно, в какой БД)
public interface OrderRepository {
    void save(Order order);
    Optional<Order> findById(Long id);
}

// Исходящий порт: как domain layer хочет взаимодействовать с платёжной системой
public interface PaymentService {
    PaymentResult processPayment(Payment payment);
}

Адаптеры

Адаптером называется конкретная реализация порта, которая интегрирует domain layer с внешней технологией.

Входящие адаптеры:

// REST адаптер: входящий адаптер, который преобразует HTTP запрос в вызов domain logic
@RestController
@RequestMapping("/orders")
public class OrderRestAdapter {
    private final CreateOrderUseCase createOrderUseCase;
    
    public OrderRestAdapter(CreateOrderUseCase createOrderUseCase) {
        this.createOrderUseCase = createOrderUseCase;
    }
    
    @PostMapping
    public ResponseEntity<OrderDTO> create(@RequestBody CreateOrderRequest request) {
        OrderResponse response = createOrderUseCase.execute(request);
        return ResponseEntity.ok(convertToDTO(response));
    }
}

Исходящие адаптеры:

// JPA адаптер: реализация OrderRepository через Spring Data JPA
@Repository
public class OrderJpaAdapter implements OrderRepository {
    private final OrderJpaRepository jpaRepository;
    
    public OrderJpaAdapter(OrderJpaRepository jpaRepository) {
        this.jpaRepository = jpaRepository;
    }
    
    @Override
    public void save(Order order) {
        OrderEntity entity = convertToEntity(order);
        jpaRepository.save(entity);
    }
    
    @Override
    public Optional<Order> findById(Long id) {
        return jpaRepository.findById(id).map(this::convertToDomain);
    }
}

// Kafka адаптер: реализация хранилища событий через Kafka
@Service
public class EventPublisherKafkaAdapter implements EventPublisher {
    private final KafkaTemplate<String, String> kafkaTemplate;
    
    @Override
    public void publish(DomainEvent event) {
        kafkaTemplate.send("events", event.toJson());
    }
}

Структура hexagonal архитектуры для Java/Spring сервиса

order-service/
├── domain/
│   ├── model/
│   │   ├── Order
│   │   ├── OrderLine
│   │   └── OrderStatus
│   ├── ports/
│   │   ├── inbound/
│   │   │   └── CreateOrderUseCase (интерфейс)
│   │   │   └── FindOrderUseCase (интерфейс)
│   │   └── outbound/
│   │       ├── OrderRepository (интерфейс)
│   │       ├── PaymentService (интерфейс)
│   │       └── NotificationService (интерфейс)
│   └── service/
│       ├── CreateOrderService (реализует CreateOrderUseCase)
│       └── FindOrderService (реализует FindOrderUseCase)
├── adapters/
│   ├── inbound/
│   │   ├── OrderRestAdapter (@RestController)
│   │   └── OrderGrpcAdapter (gRPC handler)
│   └── outbound/
│       ├── OrderJpaAdapter (@Repository, реализует OrderRepository)
│       ├── PaymentServiceHttpAdapter (HTTP client, реализует PaymentService)
│       └── NotificationServiceKafkaAdapter (Kafka publisher, реализует NotificationService)
└── config/
    └── HexagonalConfig (@Configuration, wire'ит все dependency-и)

Пример кода

// Domain model (не зависит от фреймворков)
public class Order {
    private Long id;
    private User user;
    private List<OrderLine> lines;
    private OrderStatus status;
    
    public Order(User user, List<OrderLine> lines) {
        this.user = user;
        this.lines = lines;
        this.status = OrderStatus.PENDING;
    }
    
    public void confirm() {
        if (status != OrderStatus.PENDING) {
            throw new IllegalStateException("Can only confirm pending orders");
        }
        status = OrderStatus.CONFIRMED;
    }
}

// Входящий порт
public interface CreateOrderUseCase {
    CreateOrderResponse execute(CreateOrderRequest request);
}

// Реализация входящего порта (service layer)
@Service
public class CreateOrderService implements CreateOrderUseCase {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;
    
    public CreateOrderService(OrderRepository orderRepository, PaymentService paymentService) {
        this.orderRepository = orderRepository;
        this.paymentService = paymentService;
    }
    
    @Override
    @Transactional
    public CreateOrderResponse execute(CreateOrderRequest request) {
        User user = /* получить пользователя */;
        Order order = new Order(user, request.getLines());
        
        PaymentResult result = paymentService.processPayment(order.calculateTotal());
        if (!result.isSuccess()) {
            throw new PaymentFailedException();
        }
        
        order.confirm();
        orderRepository.save(order);
        
        return new CreateOrderResponse(order.getId(), "Order created successfully");
    }
}

// Исходящий порт
public interface OrderRepository {
    void save(Order order);
    Optional<Order> findById(Long id);
}

// Реализация исходящего порта (адаптер)
@Repository
public class OrderJpaAdapter implements OrderRepository {
    private final OrderJpaRepository jpaRepository;
    
    public OrderJpaAdapter(OrderJpaRepository jpaRepository) {
        this.jpaRepository = jpaRepository;
    }
    
    @Override
    public void save(Order order) {
        OrderEntity entity = new OrderEntity();
        entity.setId(order.getId());
        // Map domain model to entity
        jpaRepository.save(entity);
    }
    
    @Override
    public Optional<Order> findById(Long id) {
        return jpaRepository.findById(id).map(entity -> {
            // Map entity to domain model
            Order order = new Order(/*...*/);
            return order;
        });
    }
}

// Входящий адаптер (REST)
@RestController
@RequestMapping("/orders")
public class OrderRestAdapter {
    private final CreateOrderUseCase createOrderUseCase;
    
    public OrderRestAdapter(CreateOrderUseCase createOrderUseCase) {
        this.createOrderUseCase = createOrderUseCase;
    }
    
    @PostMapping
    public ResponseEntity<CreateOrderResponse> create(@RequestBody CreateOrderRequest request) {
        CreateOrderResponse response = createOrderUseCase.execute(request);
        return ResponseEntity.ok(response);
    }
}

Отличие от классической layered архитектуры

Плюсы и минусы hexagonal архитектуры

Плюсы

• Domain layer полностью не зависит от фреймворков: можно тестировать бизнес-логику без Spring контекста.
• Лёгкая смена реализаций: если захотеть заменить JPA на MongoDB, меняешь только адаптер, domain и service-ы не трогаешь.
• Чёткая граница между core и внешним миром: явные входящие и исходящие порты делают архитектуру прозрачной.
• Удобна для микросервисов: каждый микросервис может быть структурирован по hexagonal, что улучшает тестируемость и поддерживаемость.

Минусы

• Больше кода на старте: нужно писать интерфейсы портов, реализации адаптеров, mapping-и между domain и DTO.
• Может быть overengineering для простых систем: если сервис — это просто CRUD с одной таблицей, hexagonal будет выглядеть как heavy machinery.
• Сложность отладки: нужно понимать flow между адаптерами, портами и service-ами.
• Требует дисциплины: легко нарушить архитектуру и "подмешать" infrastructure dependencies в domain.

Clean Architecture и Onion Architecture

Clean Architecture (Robert Martin)

Определение: архитектурный стиль, где система состоит из концентрических колец. В центре — доменные сущности (Entities), вокруг них — бизнес-правила (Use Cases), затем — interface adapters и фреймворки (Frameworks & Drivers). Зависимости всегда направлены в сторону центра, никогда наружу.

Кольца Clean Architecture

Кольцо 1: Entities (Доменные сущности)

Это сущности, содержащие бизнес-правила, которые используются многими use case-ами. Это самая стабильная часть кода, почти не меняется.

// Доменная сущность: правила применимы для многих операций
public class Order {
    private Long id;
    private List<OrderLine> lines;
    private BigDecimal totalAmount;
    
    public boolean canBeCancelled() {
        // Бизнес-правило: заказ можно отменить, только если он не доставлен
        return status != OrderStatus.DELIVERED;
    }
    
    public void addLine(OrderLine line) {
        if (line.getQuantity() <= 0) {
            throw new InvalidQuantityException();
        }
        lines.add(line);
        recalculateTotal();
    }
}

Кольцо 2: Use Cases (Бизнес-логика приложения)

Это правила, специфичные для particular use case-а. Сюда входит orchestration между несколькими entities, координация с внешними сервисами.

// Use Case: создание заказа
public class CreateOrderUseCase {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;
    private final UserFinder userFinder;
    
    public CreateOrderResponse execute(CreateOrderRequest request) {
        User user = userFinder.findById(request.getUserId());
        Order order = new Order(user, request.getLines());
        
        PaymentResult paymentResult = paymentService.charge(user, order.getTotalAmount());
        if (!paymentResult.isSuccess()) {
            throw new PaymentFailedException();
        }
        
        orderRepository.save(order);
        return CreateOrderResponse.success(order.getId());
    }
}

Кольцо 3: Interface Adapters

Это переводчики между use case-ами и внешним миром. Сюда входят REST контроллеры, Kafka listener-ы, repository реализации, HTTP client-ы для интеграции с внешними API.

// REST адаптер
@RestController
@RequestMapping("/orders")
public class CreateOrderController {
    private final CreateOrderUseCase createOrderUseCase;
    private final OrderPresenter presenter;
    
    @PostMapping
    public ResponseEntity<OrderDTO> create(@RequestBody CreateOrderRequest request) {
        CreateOrderResponse response = createOrderUseCase.execute(request);
        OrderDTO dto = presenter.present(response);
        return ResponseEntity.ok(dto);
    }
}

// Repository адаптер
@Repository
public class OrderRepositoryAdapter implements OrderRepository {
    private final OrderJpaRepository jpaRepository;
    
    @Override
    public void save(Order order) {
        OrderEntity entity = mapper.toEntity(order);
        jpaRepository.save(entity);
    }
}

Кольцо 4: Frameworks & Drivers

Это внешние библиотеки и фреймворки: Spring, Hibernate, Kafka client, HTTP library. Сюда также входит конфигурация приложения.

// Spring configuration
@Configuration
public class OrderConfig {
    @Bean
    public CreateOrderUseCase createOrderUseCase(
            OrderRepository orderRepository,
            PaymentService paymentService,
            UserFinder userFinder) {
        return new CreateOrderUseCase(orderRepository, paymentService, userFinder);
    }
    
    @Bean
    public OrderRepository orderRepository(OrderJpaRepository jpaRepository) {
        return new OrderRepositoryAdapter(jpaRepository);
    }
}

// Main application setup
@SpringBootApplication
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

Правило зависимостей Clean Architecture

Зависимости всегда направлены в сторону центра, никогда наружу. Это означает:

• Entities не знают о Use Cases.
• Use Cases не знают об Interface Adapters (контроллеры, repositories).
• Interface Adapters могут знать о Use Cases и Entities.
• Frameworks & Drivers могут знать обо всём, но это нежелательно.

Frameworks & Drivers (Spring, Kafka, HTTP)
        ↓
Interface Adapters (Controllers, Repositories)
        ↓
Use Cases (Business Logic)
        ↓
Entities (Business Rules)

Правильная зависимость:

public class CreateOrderUseCase {
    // Use Case зависит от Entity (правильно)
    public void createOrder(Order order) { }
    
    // Use Case может зависеть от Interface Adapter (через интерфейс, правильно)
    public CreateOrderUseCase(OrderRepository repository) { }
}

Неправильная зависимость:

// ❌ Entity зависит от Use Case (неправильно)
public class Order {
    private CreateOrderUseCase useCase;
}

// ❌ Entity зависит от Controller (неправильно)
public class Order {
    @Autowired
    private OrderController controller;
}

Onion Architecture (Jeffrey Palermo)

Определение: архитектурный стиль, очень похожий на Clean Architecture, но с немного другой терминологией. Система также состоит из слоёв, зависимости направлены к центру.

Слои Onion Architecture

UI Layer (Controllers, Views, REST endpoints)
        ↓
Application Services Layer
        ↓
Domain Model Layer (Entities, Value Objects, Domain Services)
        ↓
Infrastructure Layer (Database, External Services)

Отличие от Clean Architecture: Onion часто говорит про "Domain Model Layer" вместо "Entities" + "Use Cases", но суть та же — доменная логика в центре, зависимости к центру.

Связь Clean/Hexagonal/Onion

Все три архитектуры преследуют одну цель: разделить доменную логику от инфраструктурных деталей и деталей UI.

Для интервью: упомяни, что все три подхода решают одну проблему — слабую связанность domain layer от фреймворков и UI, что делает код тестируемым и гибким.

Как объяснить Clean Architecture на интервью

Кандидат может сказать:

Я предлагаю Clean Architecture. В центре — доменные сущности, содержащие основные бизнес-правила. Например, Order содержит методы для валидации заказа, расчёта суммы, определения, можно ли его отменить.

Второй слой — Use Cases, это бизнес-операции, специфичные для нашей системы. CreateOrder — это use case, он берёт пользователя, создаёт заказ, координирует платёж и сохраняет результат.

Третий слой — Interface Adapters, это REST контроллеры, repository реализации, которые преобразуют между use case-ами и техническими деталями.

И наконец, Frameworks & Drivers — это Spring, Hibernate, Kafka, которые мы используем как инструменты.

Зависимости направлены только в сторону центра. Domain layer не знает о Spring, о БД, о HTTP — это даёт нам независимость от технологий и делает код легко тестируемым. Например, я могу протестировать Order и CreateOrderUseCase вообще без Spring контекста.

Event-driven архитектура

Определение: архитектурный стиль, где компоненты взаимодействуют друг с другом асинхронно через события. Вместо прямых вызовов между сервисами (synchronous RPC), сервисы публикуют события в некий брокер (Kafka, RabbitMQ, AWS SNS), и другие сервисы подписываются на эти события.

Типы взаимодействия в event-driven системах

1. Point-to-Point (Очереди)

Модель: один издатель событий отправляет сообщение в очередь, один подписчик получает и обрабатывает это сообщение. Сообщение удаляется после обработки.

Когда использовать: когда у события ровно один потребитель, и события нужно обрабатывать в порядке FIFO.

Order Service -> Kafka Queue -> Payment Service
                 (One message)   (Processes and removes)

Технология: RabbitMQ Queue, AWS SQS, Kafka Topic с одной partition для гарантирования порядка (в контексте point-to-point).

// Издатель
@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, PaymentRequest> kafkaTemplate;
    
    public void createOrder(Order order) {
        // ...
        PaymentRequest paymentRequest = new PaymentRequest(order.getId(), order.getTotalAmount());
        kafkaTemplate.send("payment-queue", paymentRequest);
    }
}

// Подписчик
@Service
public class PaymentService {
    @KafkaListener(topics = "payment-queue", groupId = "payment-group")
    public void processPayment(PaymentRequest request) {
        // Обрабатываем платёж
        processPaymentWithProvider(request);
    }
}

2. Pub/Sub (Топики, Broadcast)

Модель: один издатель отправляет событие в топик, множество подписчиков получают копию этого события независимо друг от друга.

Когда использовать: когда событие интересует несколько сервисов (например, заказ создан → нужно отправить email, обновить статистику, отправить push-уведомление).

Order Service publishes "OrderCreated" event
        ↓
Topic: order-events
        ↙          ↓          ↘
    Email Service  Analytics Service  Notification Service
    (Independent processing)

Технология: Kafka Topic с несколькими consumer group-ами, RabbitMQ Topic exchange, AWS SNS.

// Издатель (Order Service)
@Service
public class OrderService {
    @Autowired
    private KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;
    
    public void createOrder(Order order) {
        // ...
        OrderCreatedEvent event = new OrderCreatedEvent(order.getId(), order.getUserId());
        kafkaTemplate.send("order-events", event);
    }
}

// Подписчик 1 (Email Service)
@Service
public class EmailService {
    @KafkaListener(topics = "order-events", groupId = "email-group")
    public void sendConfirmationEmail(OrderCreatedEvent event) {
        // Отправляем email
    }
}

// Подписчик 2 (Analytics Service)
@Service
public class AnalyticsService {
    @KafkaListener(topics = "order-events", groupId = "analytics-group")
    public void trackOrderCreation(OrderCreatedEvent event) {
        // Записываем в аналитику
    }
}

Domain Events vs Integration Events

Domain Events

Определение: события, которые возникают внутри bounded context-а и отражают изменения в доменной модели. Они используются для internal communication внутри одного микросервиса или context-а.

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

• Возникают как результат изменения доменной сущности (Order.confirm() → OrderConfirmed event).
• Обычно публикуются вместе с сохранением сущности (transactional outbox pattern).
• Интересуют другие компоненты в пределах одного bounded context.

// Доменное событие
public class OrderConfirmedEvent extends DomainEvent {
    private Long orderId;
    private LocalDateTime confirmedAt;
    
    public OrderConfirmedEvent(Long orderId) {
        this.orderId = orderId;
        this.confirmedAt = LocalDateTime.now();
    }
}

// Возникает в domain model
public class Order {
    private List<DomainEvent> domainEvents = new ArrayList<>();
    
    public void confirm() {
        this.status = OrderStatus.CONFIRMED;
        domainEvents.add(new OrderConfirmedEvent(this.id)); // Событие в памяти
    }
    
    public List<DomainEvent> getDomainEvents() {
        return domainEvents;
    }
}

// Публикуется application service
@Service
public class CreateOrderService {
    @Autowired
    private DomainEventPublisher eventPublisher;
    
    @Transactional
    public void createOrder(CreateOrderRequest request) {
        Order order = new Order(...);
        orderRepository.save(order);
        
        // Публикуем domain events после сохранения
        order.getDomainEvents().forEach(eventPublisher::publish);
    }
}

Integration Events

Определение: события, используемые для связи между микросервисами или bounded context-ами. Они отражают факты, важные для других сервисов.

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

• Более "стабильные" (меньше меняются), так как on them зависят другие сервисы.
• Могут включать данные для удобства подписчиков (не нужно дополнительно вызывать API издателя).
• Публикуются в shared topic/exchange, который слушают сразу несколько consumer group-ов.

// Integration Event (может отличаться от domain event)
public class OrderCreatedIntegrationEvent {
    private Long orderId;
    private Long userId;
    private BigDecimal totalAmount;
    private List<OrderItemDTO> items;
    private LocalDateTime createdAt;
    
    public OrderCreatedIntegrationEvent(Order order) {
        this.orderId = order.getId();
        this.userId = order.getUser().getId();
        this.totalAmount = order.calculateTotal();
        this.items = order.getItems().stream()
            .map(OrderItemDTO::new)
            .collect(toList());
        this.createdAt = LocalDateTime.now();
    }
}

// Публикуется в shared topic
@Service
public class OrderPublisher {
    @Autowired
    private KafkaTemplate<String, OrderCreatedIntegrationEvent> kafkaTemplate;
    
    public void publishOrderCreated(Order order) {
        OrderCreatedIntegrationEvent event = new OrderCreatedIntegrationEvent(order);
        kafkaTemplate.send("orders-topic", order.getId().toString(), event);
    }
}

Преимущества Event-driven архитектуры

• Слабая связанность: сервисы не знают друг о друге, знают только про события. Легко добавить нового подписчика без изменения издателя.
• Лучшая масштабируемость: если Email Service медленный, не влияет на Order Service. Можно масштабировать независимо.
• Гибкость: если в будущем нужно добавить интеграцию с SMS-провайдером, просто добавляем нового слушателя без изменения Order Service.
• Асинхронная обработка: тяжелые операции (отправка email, обновление аналитики) могут происходить в фоне, не блокируя создание заказа.
• Resilience: если Email Service упадёт, Order Service продолжает работать, email пошлётся позже.

Недостатки Event-driven архитектуры

• Сложность отладки: flow данных между сервисами не очевидна, нужны хорошие логи и трейсинг.
• Eventual consistency: если один сервис упадёт, данные могут быть несогласованы; нужно разбираться с retries и компенсирующими транзакциями.
• Сложное тестирование: мало кто использует event-driven локально, нужны отдельные тесты для event handlers.
• Задержка обработки: между публикацией события и его обработкой может быть задержка, система не сразу консистентна.
• Потеря событий: если сообщение в Kafka теряется, может потребоваться replay'ить события или восстанавливаться вручную.
• Порядок событий: в распределённой системе порядок может быть не гарантирован; нужны меры для обеспечения idempotency handlers.

Как проговаривать event-driven на System Design собеседовании

Кандидат может сказать:

В нашей системе будет много асинхронного взаимодействия. Когда создаётся заказ, Order Service публикует событие OrderCreated в Kafka. Это событие слушают несколько сервисов:

• Payment Service получает событие и обрабатывает платёж асинхронно.
• Email Service отправляет подтверждение пользователю.
• Analytics Service обновляет метрики.

Все эти сервисы независимы; если Email Service медленный, это не влияет на создание заказа. Если Payment Service временно недоступен, события накапливаются в Kafka и обрабатываются позже.

Для гарантирования доставки событий используем transactional outbox pattern: event сохраняется в той же транзакции, что и Order, а затем отправляется в Kafka.

CQRS (Command Query Responsibility Segregation)

Определение: архитектурный паттерн, который разделяет операции на две категории: commands (операции, изменяющие состояние: create, update, delete) и queries (операции, только читающие данные). Команды и запросы могут использовать разные модели данных и разные хранилища.

Почему классический CRUD иногда не подходит

Проблема 1: Оптимизация для чтения и записи

В типичной системе число чтений обычно в 10–100 раз больше, чем число записей. Единая модель данных часто хорошо оптимизирована для записей (нормализованная БД), но плохо для чтений.

// Классический CRUD: одна модель для чтения и записи
@Entity
public class Order {
    @Id
    private Long id;
    @ManyToOne
    private User user;
    @OneToMany
    private List<OrderLine> lines;
    @Enumerated
    private OrderStatus status;
    // ... ещё поля
}

// Для отображения списка заказов с деталями нужны дорогостоящие JOIN-ы
// SELECT o.*, u.*, ol.* FROM orders o 
// JOIN users u ON o.user_id = u.id 
// JOIN order_lines ol ON o.id = ol.order_id
// WHERE o.user_id = ?

Проблема 2: Сложные запросы требуют денормализации

Если нужно отобразить "все заказы пользователя с общей суммой по категориям товаров", нормализованная модель требует множество JOIN-ов и вычислений, что может быть медленно.

// Запрос для отчёта (сложный)
SELECT 
    category,
    COUNT(*) as item_count,
    SUM(price * quantity) as total_amount
FROM orders o
JOIN order_lines ol ON o.id = ol.order_id
JOIN products p ON ol.product_id = p.id
WHERE o.user_id = ?
GROUP BY category

CQRS решение: разные модели для записи и чтения

Command Model (Write Model)

Оптимизирован для записи, обычно нормализован, следует ACID принципам.

// Command Model (Write)
public class Order {
    private Long id;
    private Long userId;
    private List<OrderLineCmd> lines;
    private OrderStatus status;
    
    public void addLine(OrderLineCmd line) {
        // Валидация и логика добавления
        if (line.getQuantity() <= 0) throw new InvalidQuantityException();
        this.lines.add(line);
    }
}

// Command Service обрабатывает операции записи
@Service
public class CreateOrderCommandService {
    public void execute(CreateOrderCommand cmd) {
        Order order = new Order(cmd.getUserId());
        cmd.getLines().forEach(order::addLine);
        orderRepository.save(order); // Сохраняем в основное хранилище
        
        // Публикуем событие для обновления read model
        eventPublisher.publish(new OrderCreatedEvent(order.getId(), order.getUserId()));
    }
}

Query Model (Read Model)

Оптимизирован для чтения, часто денормализован, содержит только нужные поля, может быть в Elasticsearch, отдельной БД или даже in-memory кеше.

// Query Model (Read)
public class OrderReadModel {
    private Long id;
    private String userName;
    private BigDecimal totalAmount;
    private int itemCount;
    private LocalDateTime createdAt;
    // ... только то, что нужно для UI
}

// Query Service только читает
@Service
public class OrderQueryService {
    private final OrderReadRepository readRepository;
    
    public List<OrderReadModel> getUserOrders(Long userId) {
        // Простой, быстрый запрос
        return readRepository.findByUserId(userId);
    }
    
    public OrderReadModel getOrderDetails(Long orderId) {
        return readRepository.findById(orderId);
    }
}

// Repository читает из денормализованной read model БД
@Repository
public interface OrderReadRepository extends JpaRepository<OrderReadModel, Long> {
    List<OrderReadModel> findByUserId(Long userId);
}

Синхронизация между Write и Read моделью

Когда command выполняется, нужно обновить read model:

User executes command
        ↓
Command Handler processes and saves to Write DB
        ↓
Domain Event is published
        ↓
Event Handler updates Read Model (Elasticsearch, Redis, separate DB)
        ↓
Query service reads from optimized Read Model

Реализация:

// Event handler обновляет read model
@Service
public class OrderEventHandler {
    @Autowired
    private OrderReadRepository readRepository;
    
    @EventListener(OrderCreatedEvent.class)
    public void onOrderCreated(OrderCreatedEvent event) {
        // Получаем полную информацию из write model
        Order order = orderRepository.findById(event.getOrderId());
        User user = userRepository.findById(order.getUserId());
        
        // Создаём denormalized read model
        OrderReadModel readModel = new OrderReadModel();
        readModel.setId(order.getId());
        readModel.setUserName(user.getName());
        readModel.setTotalAmount(order.calculateTotal());
        readModel.setItemCount(order.getLines().size());
        
        // Сохраняем в read store (Elasticsearch, Redis и т.д.)
        readRepository.save(readModel);
    }
    
    @EventListener(OrderCancelledEvent.class)
    public void onOrderCancelled(OrderCancelledEvent event) {
        readRepository.deleteById(event.getOrderId());
    }
}

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

• Оптимизация чтения и записи отдельно: write model может быть нормализован для консистентности, read model — денормализован для скорости.
• Разные хранилища под разные задачи: write может быть PostgreSQL (ACID), read может быть Elasticsearch (fast search) или Redis (быстрое кеширование).
• Лучшая производительность на высоких нагрузках: read и write масштабируются независимо, read часто кешируется в памяти.
• Сложные запросы становятся проще: вместо JPA JOIN-ов, в read model уже есть готовые данные.

Недостатки CQRS

• Рост сложности: нужно синхронизировать две модели, обрабатывать ошибки синхронизации, восстанавливаться при сбоях.
• Eventual consistency: между write и read может быть задержка, пользователь не сразу видит изменения.
• Больше кода: нужна отдельная логика для read model, event handlers, synchronization.
• Сложность отладки: если read model не синхронизирован с write, трудно отследить, где ошибка.
• Overhead для простых систем: если система небольшая с несложными запросами, CQRS добавляет больше сложности, чем пользы.

Типичные кейсы, где CQRS оправдан

• Высокие нагрузки по чтению: социальные сети, где одна запись (пост) читается миллионами.
• Сложные запросы и отчёты: финансовые системы, аналитика, где need diverse views одних данных.
• Разные пользовательские роли: админ видит полные данные, обычный пользователь видит ограниченные.
• Интеграция с search engine-ами: Elasticsearch может быть read model для полнотекстового поиска.
• Real-time dashboard: read model постоянно обновляется, dashboard просто читает из кеша.

Как описать CQRS на System Design собеседовании

Кандидат может сказать:

Для этой системы я предлагаю использовать CQRS. Write model будет в PostgreSQL, нормализован для консистентности. Когда пользователь создаёт заказ, Order Service сохраняет его в write model и публикует OrderCreated событие.

Отдельно поддерживаем Read Model, которая денормализована и оптимизирована для быстрого чтения. Когда приходит OrderCreated событие, Event Handler обновляет Read Model, добавляя с кешированием в Redis. Когда пользователь смотрит список своих заказов, мы просто читаем из Redis, без дорогостоящих JOIN-ов.

Это даёт нам независимую масштабируемость: write может обрабатывать много команд, read может быть оптимизирована для быстрого чтения. Между write и read может быть небольшая задержка (eventual consistency), но это нормально для этого юз-кейса.

Event Sourcing

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

Как выглядит модель данных при Event Sourcing

Традиционный подход (State Storage)

Orders Table
┌─────┬──────────────┬─────────┐
│ id  │ user_id      │ status  │
├─────┼──────────────┼─────────┤
│ 1   │ 100          │ SHIPPED │
└─────┴──────────────┴─────────┘

Проблема: мы не знаем, как заказ пришёл в статус SHIPPED. Была ли переплата? Был ли возврат? История потеряна.

Event Sourcing подход (Event Stream)

Order Events Table / Event Store
┌─────┬──────────────┬─────────────────────┬────────────┬─────────┐
│ seq │ aggregate_id │ event_type          │ event_data │ timestamp
├─────┼──────────────┼─────────────────────┼────────────┼─────────┤
│ 1   │ 1            │ OrderCreated        │ {...}      │ 10:00
│ 2   │ 1            │ PaymentProcessed    │ {...}      │ 10:01
│ 3   │ 1            │ OrderConfirmed      │ {...}      │ 10:02
│ 4   │ 1            │ OrderShipped        │ {...}      │ 10:05
└─────┴──────────────┴─────────────────────┴────────────┴─────────┘

Полная история. Мы можем восстановить состояние на любой момент времени.

Как восстанавливается состояние: Replaying и Projections

Replaying Events

// Event sourcing: восстанавливаем состояние путём replaying событий
public class Order {
    private Long id;
    private Long userId;
    private List<OrderLine> lines;
    private OrderStatus status;
    private BigDecimal totalAmount;
    
    // Пустой конструктор для восстановления из событий
    public Order() {}
    
    // Apply метод для каждого события
    public void apply(OrderCreatedEvent event) {
        this.id = event.getOrderId();
        this.userId = event.getUserId();
        this.lines = new ArrayList<>();
        this.status = OrderStatus.PENDING;
        this.totalAmount = BigDecimal.ZERO;
    }
    
    public void apply(OrderLineAddedEvent event) {
        OrderLine line = new OrderLine(event.getProductId(), event.getQuantity(), event.getPrice());
        this.lines.add(line);
        this.totalAmount = this.totalAmount.add(
            event.getPrice().multiply(BigDecimal.valueOf(event.getQuantity()))
        );
    }
    
    public void apply(PaymentProcessedEvent event) {
        if (event.isSuccess()) {
            this.status = OrderStatus.CONFIRMED;
        } else {
            this.status = OrderStatus.PAYMENT_FAILED;
        }
    }
    
    public void apply(OrderShippedEvent event) {
        this.status = OrderStatus.SHIPPED;
    }
}

// Восстановление заказа из события
public class OrderAggregateRepository {
    public Order getById(Long orderId) {
        List<DomainEvent> events = eventStore.getEvents(orderId);
        
        Order order = new Order();
        for (DomainEvent event : events) {
            order.apply(event); // Replaying
        }
        return order;
    }
}

Projections (Проекции)

Replaying каждый раз дорого. Используются projections — денормализованные представления, которые обновляются по мере поступления событий.

// Projection: денормализованная читаемая модель
@Entity
public class OrderProjection {
    @Id
    private Long id;
    private Long userId;
    private String userName;
    private BigDecimal totalAmount;
    private OrderStatus status;
    private LocalDateTime lastUpdated;
}

// Event Handler обновляет projection
@Service
public class OrderProjectionUpdater {
    @EventListener(OrderCreatedEvent.class)
    public void onOrderCreated(OrderCreatedEvent event) {
        OrderProjection projection = new OrderProjection();
        projection.setId(event.getOrderId());
        projection.setUserId(event.getUserId());
        projection.setStatus(OrderStatus.PENDING);
        projection.setLastUpdated(LocalDateTime.now());
        projectionRepository.save(projection);
    }
    
    @EventListener(OrderShippedEvent.class)
    public void onOrderShipped(OrderShippedEvent event) {
        OrderProjection projection = projectionRepository.findById(event.getOrderId());
        projection.setStatus(OrderStatus.SHIPPED);
        projection.setLastUpdated(LocalDateTime.now());
        projectionRepository.save(projection);
    }
}

// Запрос к projection (быстро)
public class OrderQueryService {
    public OrderProjection getOrder(Long id) {
        return projectionRepository.findById(id);
    }
}

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

• Полная история изменений: каждое событие сохранено, можем аудировать, кто что когда сделал.
• Возможность переиграть события: если хотим изменить бизнес-логику обработки события, можем переиграть исторические события с новой логикой.
• Временные запросы: можем запросить состояние сущности на любой момент времени (например, какой был статус заказа неделю назад).
• Отладка: если система дала неправильный результат, можем проследить все события, которые привели к этому состоянию.
• Синергия с CQRS: event sourcing естественно дополняет CQRS, события используются для обновления read model.

Недостатки Event Sourcing

• Сложность реализации: нужна работающая event store, careful event design, преодоление race conditions при параллельных записях.
• Требования к дисциплине моделирования: события должны быть immutable, неизменяемы по смыслу (если решили переименовать OrderCreated в CreateOrder, это breaking change для всех старых событий).
• Сложные миграции: если нужно изменить структуру события (добавить поле), нужно мигрировать все исторические события.
• Состояние растёт: с течением времени событий становится всё больше, replaying может замедлиться (решается через snapshots).
• Операционная сложность: нужна надёжная event store, backup-и, мониторинг целостности события.

Snapshots для оптимизации

Если событий миллионы, replaying может быть медленным. Используются snapshots — "контрольные точки" состояния.

// Snapshot: сохранённое состояние на определённый момент
public class OrderSnapshot {
    private Long aggregateId;
    private Integer version; // Версия события, к которой относится snapshot
    private Order aggregateState; // Сохранённое состояние
}

// Восстановление с snapshots
public class OrderAggregateRepository {
    public Order getById(Long orderId) {
        // 1. Получаем последний snapshot
        Optional<OrderSnapshot> snapshot = snapshotStore.getLatest(orderId);
        
        Order order;
        int fromVersion = 0;
        if (snapshot.isPresent()) {
            order = snapshot.get().getAggregateState();
            fromVersion = snapshot.get().getVersion();
        } else {
            order = new Order();
        }
        
        // 2. Replaying только событий после snapshot
        List<DomainEvent> recentEvents = eventStore.getEvents(orderId, fromVersion);
        for (DomainEvent event : recentEvents) {
            order.apply(event);
        }
        
        return order;
    }
}

Когда Event Sourcing оправдан, а когда это оверинжиниринг

Event Sourcing оправдан:

• Требование к полной истории: финансовые системы, где нужна полная аудиторская трасса.
• Сложная бизнес-логика: если понять текущее состояние сложно, полная история помогает разобраться.
• Интеграция с внешними системами: если нужно синхронизировать с несколькими внешними системами, история событий помогает восстанавливаться после сбоев.
• Масштабные системы: event sourcing хорошо работает с CQRS для высоконагруженных приложений.

Оверинжиниринг (когда не использовать Event Sourcing):

• Простые CRUD системы: если просто читаем и пишем в БД, event sourcing добавляет ненужную сложность.
• Короткая история: если события хранятся недолго и удаляются (например, через неделю), смысла в полной истории нет.
• Real-time требования: если нужна очень низкая latency, replaying событий может быть медленнее, чем просто чтение состояния.

Комбинирование архитектурных стилей и паттернов

На практике архитектурные стили и паттерны редко используются в чистом виде. Обычно комбинируются несколько для решения разных проблем. Интервьюер ценит кандидата, который понимает, как и когда комбинировать.

Модульный монолит + Event-driven внутри одного приложения

Сценарий: система выросла в модульный монолит (100 тыс. строк), но отдельные модули по-прежнему могут независимо развиваться.

Проблема: синхронное взаимодействие между модулями (order-module вызывает payment-module) приводит к слабой развязке и сложности тестирования.

Решение: используем async event-driven communication внутри монолита.

// Order Module: публикует событие
public class OrderService {
    @Autowired
    private ApplicationEventPublisher eventPublisher;
    
    public void createOrder(CreateOrderRequest request) {
        Order order = new Order(...);
        orderRepository.save(order);
        
        // Публикуем event вместо прямого вызова
        eventPublisher.publishEvent(new OrderCreatedEvent(order.getId()));
    }
}

// Payment Module: слушает событие
@Component
public class PaymentEventListener {
    @EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        // Обрабатываем платёж асинхронно
        processPayment(event.getOrderId());
    }
}

// Преимущества:
// - order-module не знает о payment-module (слабая связанность)
// - легко тестировать payment отдельно
// - если payment долгая операция, можно использовать @Async

Микросервисы + Event-driven + CQRS (типичный high-load сценарий)

Сценарий: high-load система с несколькими микросервисами, нужна высокая масштабируемость и читки, и записи.

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

┌──────────────────────┐
│   API Gateway        │
└─────────┬────────────┘
          │
    ┌─────┴─────────────────────────────────────┐
    │                                           │
┌───▼──────────┐                    ┌──────────▼──────┐
│ Order        │                    │ Product         │
│ Microservice │                    │ Microservice    │
├──────────────┤                    ├─────────────────┤
│ Write Model  │                    │ Write Model     │
│ (PostgreSQL) │                    │ (PostgreSQL)    │
│              │                    │                 │
│ Read Model   │                    │ Read Model      │
│ (Elasticsearch)                   │ (Redis Cache)   │
└───┬──────────┘                    └────┬────────────┘
    │ Events                             │ Events
    └──────────────┬──────────────────────┘
                   │
            ┌──────▼──────┐
            │ Kafka Topic │
            │  (events)   │
            └─────────────┘

Детально:

• Каждый микросервис имеет CQRS: order-service имеет write model в PostgreSQL и read model в Elasticsearch.
• Event-driven связь между сервисами: когда Order Service создаёт заказ, он публикует OrderCreated событие в Kafka.
• Read model обновляется асинхронно: Event Handler слушает события из других сервисов и обновляет свой read model.

// Order Service: Write command
@Service
public class CreateOrderCommandService {
    public void execute(CreateOrderCommand cmd) {
        Order order = new Order(cmd.getUserId(), cmd.getItems());
        orderRepository.save(order); // Write model
        eventPublisher.publish(new OrderCreatedEvent(order.getId(), order.getUserId()));
    }
}

// Order Service: Read query
@Service
public class OrderQueryService {
    @Autowired
    private OrderReadRepository elasticsearchRepository;
    
    public List<OrderDTO> getUserOrders(Long userId) {
        // Читаем из Elasticsearch, быстро
        return elasticsearchRepository.findByUserId(userId);
    }
}

// Payment Service: слушает события от Order Service
@Service
public class PaymentEventListener {
    @KafkaListener(topics = "order-events", groupId = "payment-group")
    public void onOrderCreated(OrderCreatedEvent event) {
        processPayment(event.getOrderId());
        // Публикует свои события
        eventPublisher.publish(new PaymentProcessedEvent(event.getOrderId()));
    }
}

Преимущества этого комбо:

• Write и read масштабируются независимо.
• Микросервисы слабо связаны через events.
• Read model оптимизирована для быстрого поиска.
• При падении одного микросервиса остальные продолжают работать.

Недостатки:

• Высокая сложность инфраструктуры (Kubernetes, Kafka, Elasticsearch, мониторинг).
• Eventual consistency требует тщательной обработки ошибок.
• Нужна expertise в распределённых системах.

Hexagonal/Clean Architecture внутри каждого микросервиса

Сценарий: микросервисная архитектура, но каждый сервис нужно сделать гибким и тестируемым.

Решение: внутри каждого микросервиса используем hexagonal или clean architecture.

Order Microservice
├── domain/
│   ├── model/
│   │   └── Order, OrderLine (не зависят от фреймворков)
│   └── ports/
│       ├── OrderRepository (интерфейс)
│       └── PaymentService (интерфейс)
├── application/
│   ├── CreateOrderService (реализует CreateOrderUseCase)
│   └── FindOrderService (реализует FindOrderUseCase)
├── adapters/
│   ├── inbound/
│   │   ├── OrderRestAdapter (@RestController)
│   │   └── OrderEventAdapter (Kafka listener)
│   └── outbound/
│       ├── OrderJpaRepository (@Repository)
│       ├── PaymentHttpClient (HTTP адаптер к платёжному сервису)
│       └── EventPublisherKafka (Kafka publisher)
└── config/
    └── OrderMicroserviceConfig

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

• Domain logic полностью независима от Spring, Kafka, и т.д.
• Легко заменить реализацию (например, БД).
• Хорошо тестируется.
• Гибкость при эволюции микросервиса.

Эволюция архитектуры

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

Путь "монолит → модульный монолит → микросервисы"

Этап 1: Простой монолит (Startup, MVP)

Когда: первые месяцы, нужно быстро проверить гипотезу.

Архитектура: одно приложение, одна БД, все компоненты в одном процессе.

┌─────────────────────────────┐
│     Spring Boot App         │
├─────────────────────────────┤
│  Controllers                │
│  Services (Order, User)     │
│  Repositories               │
└─────────────────────────────┘
         ↓
    PostgreSQL

Размер команды: 1–3 разработчика.

Проблемы: нет, система маленькая.

Этап 2: Модульный монолит (Растущий стартап)

Когда: 6–12 месяцев, система достигла 50–100 тыс. строк кода, выявились явные модули.

Архитектура: одно приложение, но разбито на bounded context-ы (user, order, payment, notification), каждый с явной границей.

┌─────────────────────────────────────────────┐
│       Spring Boot App (модульный)           │
├──────────────┬──────────────┬────────────────┤
│ User Module  │ Order Module │ Payment Module │
├──────────────┼──────────────┼────────────────┤
│ domain/      │ domain/      │ domain/        │
│ application/ │ application/ │ application/   │
│ api/         │ api/         │ api/           │
└──────────────┴──────────────┴────────────────┘
         ↓
    PostgreSQL

Размер команды: 5–10 разработчиков, каждый работает на модулем.

Проблемы из этапа 1, которые решаются:

• Границы между модулями ясны, нет хаотичных зависимостей.
• Изменения в одном модуле не ломают другие.
• Командам проще разрабатывать параллельно.

Новые проблемы:

• Модули растут, некоторые достаточно большие для отдельного сервиса.
• Разные модули нужны в разных масштабах (product search нужна масса replicas, auth может быть 1-2).

Этап 3: Микросервисы (Масштабный сервис)

Когда: 12–24 месяца, система требует разной масштабируемости по компонентам, разные команды нужна полная автономность.

Архитектура: отдельные микросервисы с собственными БД, асинхронная связь через события.

API Gateway
    ↓
┌───────────┬───────────┬──────────────┐
│User API   │Order API  │Payment API   │
├───────────┼───────────┼──────────────┤
│PostgreSQL │PostgreSQL │PostgreSQL    │
└────┬──────┴─────┬─────┴───────┬──────┘
     │            │              │
     └────────────┴──────────────┘
            Kafka (events)

Размер команды: 20–50 разработчиков, каждой команде дан микросервис.

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

• User Service масштабируется независимо от Order Service.
• Платёжный API может быть отказоустойчивым: если платёж падает, заказы всё равно создаются (в очередь).
• Каждая команда может использовать свой стек (Java, Go, Node).

Проблемы этапа 3:

• Сложность инфраструктуры (Kubernetes, observability, circuit breaker).
• Distributed transactions (saga паттерн).
• Eventual consistency усложняет бизнес-логику.

Какие сигналы говорят, что пора выходить за рамки монолита

Сигнал 1: Разные скорости изменений по модулям

Если payment-module меняется раз в месяц, а order-module раз в день, они тормозят друг друга в монолите (разные версии выпусков, разные testing cycles).

Каждый выпуск монолита требует:

- тестирования всего кода
- координации изменений между модулями
- синхронизации версий
→ Конфликты, задержки, баги в production

Решение: вывести в отдельный микросервис.

Сигнал 2: Независимые команды

Когда у company есть Team A (users), Team B (orders), Team C (payments), они мешают друг другу в одном монолите. Каждой команде нужна своя версия кода, свои releaseCycle.

Решение: дать каждой команде свой микросервис.

Сигнал 3: Ограничения по масштабированию

Если Product Search нужны 50 instances, но ещё 49 instances других компонентов монолита будут пусты и тратить ресурсы.

Решение: выделить service в отдельный микросервис, масштабировать независимо.

Сигнал 4: Разные требования к надёжности и SLA

Если payment service требует 99.99% uptime, а обычный user service может быть 99.9%, в монолите это трудно достичь.

Решение: микросервис может иметь отдельную инфра с более высокими требованиями.

Как рассказывать про эволюцию архитектуры на интервью

На собеседовании кандидат может сказать:

Я предлагаю начать с модульного монолита. Это позволит быстро проверить идею, запустить систему за недели. В монолите выделим явные bounded context-ы: user, order, payment. Каждый модуль будет иметь свою логику, свои repository, но все в одном приложении.

По мере роста, если сигналы покажут, что отдельные модули нужна разная масштабируемость или разные команды, мы постепенно выведем их в микросервисы. Например, когда product search нужна масса машин, выведем его в отдельный Product Service. Когда payment требует 99.99% uptime, выведем в отдельный Payment Service.

К году, если система вырастет, может получиться 5–10 микросервисов. Но главное — это эволюция, а не спешка в микросервисы с самого начала. Монолит даёт простоту, микросервисы дают масштабируемость.

Как выбирать архитектурный стиль под задачу на собеседовании

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

Тип задач и рекомендуемые архитектурные стили

Задача 1: Простой CRUD-сервис (REST API для БД)

Требования: создание, чтение, обновление, удаление записей. Нагрузка небольшая (10K–100K RPS).

Пример: каталог товаров, управление пользователями.

Рекомендуемая архитектура: Слоистая архитектура или Hexagonal (если нужна гибкость).

User Request
    ↓
REST Controller (Presentation)
    ↓
Service Layer (Business Logic)
    ↓
Repository (Data Access)
    ↓
PostgreSQL

Почему не микросервисы: нет необходимости в независимом масштабировании, система простая.

Задача 2: Социальная сеть (Instagram-like)

Требования: много пользователей, фиды, лайки, комментарии, нужна высокая read throughput.

Пример: Instagram, Twitter.

Рекомендуемая архитектура: Микросервисы + CQRS + Event-driven.

Микросервисы:

- User Service (профили, follow)
- Post Service (создание постов)
- Feed Service (фиды)
- Like Service (лайки)

Взаимодействие:

- Event-driven: Post Service публикует PostCreated → Feed Service обновляет фиды
- CQRS: Post Service пишет в PostgreSQL, читает из Redis/Elasticsearch

Read-heavy: фиды читаются в 1000 раз чаще, чем создаются посты
→ Нужна специальная read model

Почему микросервисы: разные масштабируемости (Feed Service нужен huge cache), разные SLA.

Почему CQRS: много read-ов, нужна оптимизированная read model.

Задача 3: Система покупок (e-commerce)

Требования: заказы, платежи, inventory, доставка. Нужна транзакционность и надёжность.

Рекомендуемая архитектура: Модульный монолит (если нагрузка умеренная) или Микросервисы + Saga для транзакций.

Модульный монолит:

- User Module
- Product Module  
- Order Module (с Saga паттерном для multi-step заказа)
- Payment Module
- Inventory Module

Взаимодействие:

- Event-driven: создание заказа → проверка inventory → обработка платежа → отправка email
- Saga паттерн для управления распределённой транзакцией

Почему не просто микросервисы: нужна ACID для заказов. Saga добавляет сложность, но если нагрузка умеренная, модульный монолит проще и надёжнее.

Задача 4: Real-time система (Uber, ride-sharing)

Требования: real-time обновления (ride position), нужна низкая latency, high concurrency.

Рекомендуемая архитектура: Микросервисы + Event-driven + WebSocket.

Микросервисы:

- Matching Service (находит водителя для пассажира)
- Ride Service (управление поездкой)
- Location Service (real-time позиции)
- Payment Service

Взаимодействие:

- WebSocket: browser получает обновления позиции в real-time
- Event-driven: Location Service публикует LocationUpdated → все подписчики узнают о перемещении
- Low latency требует оптимизирования (in-memory кеши, Redis)

Почему event-driven: нужна асинхронная обработка для скорости.

Задача 5: Финансовая система (платежи, переводы)

Требования: надёжность, auditability, консистентность, никаких потерь денег.

Рекомендуемая архитектура: Модульный монолит с Event Sourcing.

Модульный монолит:

- Account Module (управление счётами)
- Transaction Module (переводы)
- Payment Module (платежи)

Event Sourcing:

- Каждая операция сохраняется как событие
- State восстанавливается replaying событий
- Полная history для аудита

Почему Event Sourcing: финансовые регуляторы требуют полной истории всех операций. Event Sourcing даёт это из коробки.

Задача 6: Аналитика и BigData (события с множеством источников)

Требования: собрать события с множества источников, обработать, сохранить для анализа.

Рекомендуемая архитектура: Event-driven + CQRS, Kafka + Data Lake.

Event Sources
    ↓
Kafka (event stream)
    ↓
Processing Layer (Stream processing: Spark, Flink)
    ↓
Data Lake (S3, HDFS) + Analytics DB (Snowflake)
    ↓
BI Dashboard

Почему event-driven: события идут с множества источников, асинхронная обработка.

Почему CQRS: нужна разделение между потоком событий (write) и аналитическими запросами (read).

Какие вопросы о требованиях помогают сделать выбор

На собеседовании, прежде чем выбирать архитектуру, кандидат должен задать вопросы:

1. Масштаб нагрузки: 1000 RPS или 1M RPS? Это определяет, нужны ли микросервисы.
2. Соотношение читок к писькам: 1:1 или 100:1? Если много читок, нужна CQRS.
3. Требования к консистентности: ACID или eventual consistency? Финансовые системы требуют ACID, социальные сети могут терпеть eventual consistency.
4. Требования к latency: микросекунды или секунды? Real-time требует других архитектур, чем batch processing.
5. Размер команды: 1 разработчик или 100? Влияет на выбор между монолитом и микросервисами (conway's law).
6. История данных: нужна ли полная история? Event Sourcing vs State storage.
7. Требуемая надёжность (SLA): 99.9% или 99.99%? Влияет на выбор инфраструктуры и подхода к отказоустойчивости.

Как объяснить решение

После выбора архитектурного стиля, кандидат должен объяснить:

1. Почему выбран именно этот стиль: "Выбираю микросервисы, потому что нужна высокая read throughput и независимое масштабирование компонентов."
2. Какие альтернативы были рассмотрены: "Рассматривал модульный монолит, но при 1M RPS он не масштабируется достаточно, микросервисы дают нам гибкость."
3. Какие trade-off'ы: "Микросервисы добавляют complexity в инфраструктуре, но выигрыш в масштабируемости стоит того."

Примеры кратких "шаблонных" объяснений

Когда уместен модульный монолит

Я предлагаю модульный монолит. Система начинается с нескольких чётко определённых модулей (user, order, payment), нагрузка умеренная (100K RPS). Модульный монолит даёт нам простоту развёртывания и ACID транзакции между модулями. Если позже один из модулей потребует независимого масштабирования, мы сможем выделить его в отдельный микросервис без переписания логики.

Когда сразу говорить про микросервисы

Я предлагаю микросервисы с event-driven связью. Система требует 1M RPS, разные компоненты (feed, search, payment) имеют разные требования к масштабируемости и надёжности. Event-driven подход даёт нам асинхронную обработку, лучшую отказоустойчивость и слабую связанность. Каждый сервис может развиваться независимо.

Чек-лист обсуждения архитектурного стиля на System Design

Интервьюер ожидает, что кандидат будет структурировано проходить по архитектуре. Вот чек-лист пунктов, которые обязательно упомянуть:

Обязательные пункты

1. Разбиение на компоненты/сервисы/модули

Кандидат должен явно назвать основные компоненты системы.

Example answer:
"Система состоит из пяти микросервисов: User Service (авторизация, профили), 
Product Service (каталог), Order Service (заказы), Payment Service (платежи), 
Notification Service (отправка email/SMS)."

2. Границы ответственности

Каждый компонент должен иметь ясную ответственность.

Example answer:
"User Service отвечает только за управление профилями и авторизацией. 
Product Service отвечает за каталог товаров. Order Service координирует 
создание заказов и вызывает Payment Service для обработки платежа."

3. Модель данных и где живёт "истина"

Какие данные хранятся где? Где единый источник истины?

Example answer:
"Каждый микросервис имеет собственную БД. User Service имеет таблицу Users в PostgreSQL. 
Product Service имеет таблицу Products также в PostgreSQL. Order Service имеет Orders и 
OrderLines, но также может читать кеш Products из Redis."

4. Синхронные взаимодействия

REST, gRPC вызовы между компонентами. Когда используются?

Example answer:
"Order Service синхронно вызывает Product Service при создании заказа для 
проверки наличия товара. Это безопасно, потому что эта операция должна быть атомарной."

5. Асинхронные взаимодействия

События, очереди, Kafka topics.

Example answer:
"После успешного создания заказа Order Service публикует OrderCreated событие в Kafka. 
Payment Service слушает на этот topic и обрабатывает платёж асинхронно. 
Notification Service отправляет email пользователю."

6. Fault tolerance

Как система обрабатывает сбои?

Example answer:
"Если Payment Service недоступен, заказ остаётся в статусе PENDING, а событие 
остаётся в Kafka. Retry handler повторяет попытку платежа через 5 минут, максимум 
3 раза. Если платёж неудачен после 3 попыток, заказ переходит в статус PAYMENT_FAILED."

7. Scaling

Как компоненты масштабируются?

Example answer:
"Каждый микросервис может быть масштабирован независимо. Например, Product Service 
может иметь 50 instances, в то время как User Service может работать с 5. 
Используем Kubernetes для оркестрации."

8. Observability

Логирование, метрики, трейсинг.

Example answer:
"Все логи агрегируются в ELK stack. Метрики собираются Prometheus. 
Трейсинг выполняется через Jaeger, каждый запрос имеет trace ID, 
который распространяется между всеми микросервисами."

Пример структурированного ответа: 7 шагов

Кандидат может следовать этому плану:

1. High-level overview: "Система состоит из X микросервисов, общающихся через REST API и Kafka."

2. Каждый микросервис в отдельности: "User Service отвечает за... Product Service отвечает за..."

3. Модели данных: "Каждый сервис имеет свою БД: User в PostgreSQL, Products в Elasticsearch..."

4. Синхронные вызовы: "Order Service вызывает Product Service для проверки наличия..."

5. Асинхронные события: "После создания заказа публикуется OrderCreated событие..."

6. Обработка ошибок: "Если платёж падает, используется saga паттерн для компенсации..."

7. Неё-функциональные требования: "Масштабируемость через Kubernetes, логирование через ELK..."

Типичные ошибки при обсуждении архитектурных стилей на собеседовании

Даже опытные разработчики совершают ошибки при обсуждении архитектуры на интервью. Вот список типичных и как их избежать.

Ошибка 1: Автоматический выбор микросервисов без аргументов

Неправильно:

Я предлагаю микросервисы. Это современная архитектура, её все используют. User Service, Product Service, Order Service, всё separate.

Проблема: нет обоснования. Интервьюер не видит понимания trade-off'ов.

Правильно:

Система требует 1M RPS, разные компоненты нужна разная масштабируемость. Product search может потребовать 100 instances, а auth может работать с 5. Микросервисы позволяют это. Однако это добавляет complexity инфраструктуры. Альтернатива — модульный монолит, если нагрузка умеренная, но для этой системы микросервисы оправданы.

Ошибка 2: Использование модных слов без понимания

Неправильно:

Используем CQRS и Event Sourcing. И ещё SAGA паттерн для транзакций.

Проблема: нет понимания, когда это нужно и какие это добавляет сложности.

Правильно:

CQRS используем, потому что read-load в 100 раз превышает write-load. Write model остаётся в PostgreSQL (нормализованная), read model в Elasticsearch (денормализованная, оптимизирована для search). Event handlers синхронизируют между ними.

Ошибка 3: Перегрузка деталей на уровне классов вместо архитектуры

Неправильно:

У нас будет UserService с методом createUser(), getUser()... и ещё OrderService с createOrder()...

Проблема: кандидат говорит про классы вместо архитектуры система. На System Design собеседовании важна система-уровень архитектура.

Правильно:

На уровне архитектуры система разбита на 5 микросервисов. Каждый микросервис имеет REST API для других сервисов и Kafka topic для event-driven общения. Внутри каждого микросервиса используем layered или hexagonal архитектуру.

Ошибка 4: Игнорирование организационного контекста

Неправильно:

Проектирую систему в вакууме, без учёта, как её будут разрабатывать и эксплуатировать.

Проблема: архитектура должна соответствовать организации (conway's law). Если нет DevOps команды, микросервисы будут nightmare.

Правильно:

Система разбита на 3 микросервиса, потому что в company есть 3 teams, каждой дан свой сервис. У нас есть DevOps team для управления Kubernetes. Если бы была одна team, предложил бы модульный монолит.

Ошибка 5: Отсутствие осознанных trade-off'ов

Неправильно:

Микросервисы лучше, чем монолит. Конец.

Проблема: нет понимания, что всё имеет цену.

Правильно:

Микросервисы дают независимое масштабирование и гибкость для teams, но добавляют операционную сложность (Kubernetes, observability, distributed tracing). Для небольшой системы (< 10K RPS) монолит проще и надёжнее. Для высоконагруженной системы (1M+ RPS) complexity микросервисов оправдана.

Ошибка 6: Использование модных архитектур там, где они не подходят

Неправильно:

Event Sourcing везде, это же лучше всех! Все события сохраняются, можем переиграть историю.

Проблема: Event Sourcing добавляет сложность миграции и требует дисциплины. Для простой системы CRUD это оверинжиниринг.

Правильно:

Event Sourcing используем только для domain-intensive operations, где важна полная история. Например, финансовые операции (каждый перевод должен быть audit-able). Для CRUD операций достаточно обычного state storage.

Рекомендации: как звучать как senior, а не как "архитектор по мемам из интернета"

1. Задавайте уточняющие вопросы: не кидайтесь в дизайн, спросите про требования, нагрузку, команду.

2. Обосновывайте каждый выбор: не просто "микросервисы", а "микросервисы, потому что нужна независимая масштабируемость компонентов, потому что [конкретные требования]".

3. Обсуждайте trade-off'ы: "Монолит дал бы нам [плюсы], но микросервисы дают [другие плюсы]. Для этого случая микросервисы лучше, потому что".

4. Эволюция, а не революция: не "сразу микросервисы", а "начнём с модульного монолита, потом эволюционируем в микросервисы".

5. Учитывайте организацию: "System должна соответствовать структуре teams."

6. Не используйте паттерны просто так: CQRS, Event Sourcing, SAGA — не потому что "это modern", а потому что решают конкретные проблемы.

7. Обсуждайте операционный контекст: не только код, но и как это развёртывается, масштабируется, мониторится.

8. Признавайте сложность: "Это добавляет complexity, но выигрыш в [масштабируемость/надёжность/гибкость] стоит того."

Итоговые мысли для подготовки к собеседованию

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

Главное, что нужно помнить

1. Нет идеальной архитектуры: каждый стиль имеет плюсы и минусы. Выбор зависит от requirements.

2. Архитектура эволюционирует: начните с простого (монолит), добавляйте complexity по мере необходимости.

3. Обосновывайте выбор: не потому что "это modern", а потому что решает конкретные требования.

4. Думайте о trade-off'ах: масштабируемость vs complexity, consistency vs availability, fast delivery vs maintainability.

5. Комбинируйте паттерны: микросервисы + CQRS + Event-driven часто используются вместе.

6. Организация важна: архитектура должна соответствовать structure организации.

7. Говорите структурировано: используйте чек-лист (компоненты, граны, модели данных, sync/async, fault tolerance).

Опытный кандидат на интервью не просто выбирает архитектурный стиль, а рассказывает историю о том, как система эволюционирует от простого монолита к сложной распределённой системе, и почему в каждый момент времени выбран именно этот стиль.

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

Введение

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

Базовые сетевые концепции

Задержка (latency)

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

Типичные значения:

• Обращение в один дата-центр: 1–5 мс
• Региональное взаимодействие (внутри страны): 10–50 мс
• Трансконтинентальный запрос (Нью-Йорк ↔ Сингапур): 100–300 мс

Влияние на дизайн: задержка накапливается при синхронных цепочках вызовов. Запрос вида A → B → C с задержкой 5 мс на каждый скачок требует минимум 10 мс на передачу данных, не считая обработки.

Пропускная способность (throughput) и ширина канала (bandwidth)

Пропускная способность — объём данных, успешно доставленных за единицу времени (Гбит/с, МБ/с, запросов/сек).

Ширина канала — теоретическое максимальное значение пропускной способности.

Типичные значения:

• Между серверами в дата-центре: 10 Гбит/с
• На одну машину: 1 Гбит/с
• Через интернет: 100 Мбит/с – 1 Гбит/с

Расчёт требуемой полосы пропускания:

Если API обслуживает 100 000 запросов в секунду (RPS), каждый запрос весит 1 КБ (размер тела + заголовки), то требуемая пропускная способность:

(100,000 \times 1,\text{КБ} = 100,\text{МБ/с} = 800,\text{Мбит/с})

Добавляя оверхед протокола TCP/IP (~10%), получаем реальное требование: 880 Мбит/с.

Время в оба конца (RTT)

Время, за которое пакет идёт до получателя и возвращается обратно.

Влияние на протоколы:

• Установление TCP-соединения (трёхфазное рукопожатие): примерно 3 × RTT
• TLS handshake поверх TCP: дополнительно 2–3 × RTT

Пример: при RTT = 10 мс, установление защищённого соединения требует примерно 50 мс. Цепочка из пяти независимых соединений потребует 250 мс только на handshake'и.

TCP и UDP: выбор протокола транспортного уровня

TCP (Transmission Control Protocol)

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

• Гарантирует доставку всех пакетов в правильном порядке
• При потере пакета переотправляет его автоматически
• Требует установления соединения (трёхфазное рукопожатие)
• Добавляет overhead для проверок и переотправок

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

• Backend-API взаимодействие (потеря запроса неприемлема)
• Микросервисное взаимодействие
• Любые операции, требующие гарантии целостности данных
• Финансовые операции, критичные бизнес-процессы

UDP (User Datagram Protocol)

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

• Отправляет пакеты без гарантии доставки или порядка
• Отсутствует overhead установления соединения
• Минимальная задержка

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

• Real-time трафик (видеостриминг, VoIP), где небольшие потери приемлемы
• Системы мониторинга и аналитики, допускающие потерю отдельных пакетов
• DNS-запросы

Практический вывод: в backend-архитектуре микросервисов используется почти исключительно TCP, так как надёжность более важна, чем минимальная задержка.

Трёхфазное рукопожатие TCP и его влияние на задержки

Перед отправкой данных через TCP выполняется трёхфазное соединение:

1. Клиент отправляет SYN
2. Сервер отвечает SYN-ACK
3. Клиент отправляет ACK

При RTT = 10 мс минимальная задержка установления соединения составляет 30 мс.

Проблема при наивном подходе: если приложение создаёт новое соединение для каждого запроса в цепочке из пяти синхронных вызовов, общая задержка только на handshake'и будет 5 × 30 = 150 мс.

Решение: использование пула соединений. Соединения переиспользуются для нескольких запросов подряд, амортизируя стоимость handshake'а.

TLS/HTTPS: шифрование и аутентификация

Назначение TLS

TLS (Transport Layer Security) обеспечивает:

• Конфиденциальность: данные зашифрованы, третья сторона не может их прочитать
• Целостность: данные не могут быть подделаны или изменены
• Аутентификация: сервер доказывает свою подлинность через сертификат

TLS handshake и стоимость

После установления TCP-соединения (3 RTT) выполняется TLS handshake (дополнительно 2–3 RTT в зависимости от версии).

Итого: ~50 мс на установление защищённого соединения при RTT = 10 мс.

Оптимизация: TLS termination на edge

В production-архитектурах TLS расшифровывается на edge (балансировщик нагрузки, reverse proxy):

1. Клиент отправляет HTTPS-запрос → edge LB расшифровывает
2. Внутри trusted сети (дата-центр) трафик идёт unencrypted HTTP или по mTLS
3. Это экономит CPU на backend-серверах
4. Управление сертификатами централизовано

HTTP-протоколы

HTTP/1.1

Механизм сохранения соединения (keep-alive): в HTTP/1.0 каждый запрос требовал отдельного TCP-соединения. HTTP/1.1 ввёл keep-alive — одно соединение переиспользуется для нескольких запросов.

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

HTTP/2

Решает основные проблемы HTTP/1.1.

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

• Мультиплексирование: один TCP-скачок несёт несколько виртуальных потоков (streams). Запросы и ответы могут идти в произвольном порядке. Блокировка в начале очереди решена на HTTP-уровне.

• Сжатие заголовков (HPACK): повторяющиеся заголовки передаются индексами, не полными значениями.

• Отправка сервером (Server Push): сервер может отправить ресурсы до того, как клиент их запросит (например, CSS вместе с HTML).

• Бинарный формат: проще парсить, чем текстовый HTTP/1.1.

Применение: gRPC использует HTTP/2 как транспорт. Благодаря мультиплексированию тысячи параллельных RPC-вызовов могут идти по одному соединению без перехватывания друг друга.

HTTP/3 (QUIC)

Построен на QUIC — протоколе поверх UDP, а не TCP.

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

• 0-RTT соединение: если клиент уже подключался, новое соединение устанавливается без задержек
• Миграция соединения: если клиент переехал с WiFi на 4G, соединение не разрывается
• Лучшая задержка: нет блокировки на TCP-уровне (TCP переотправляет потерянные пакеты, блокируя всех остальных)

Статус (конец 2025): широко поддерживается браузерами и CDN, но в backend'е редко используется.

WebSocket и паттерны для двусторонней связи

Для real-time взаимодействия (уведомления, live-обновления) требуется двусторонняя или server-initiated связь.

WebSocket: после начального HTTP upgrade на ws://, это чистый TCP с минимальным оверхедом.

События от сервера (SSE): долгоживущее соединение, только сервер инициирует отправку. Проще WebSocket, если не нужна двусторонняя связь.

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

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

Синхронные паттерны вызовов

REST/JSON

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

• HTTP запрос с JSON payload, ответ в JSON
• Стандартные HTTP методы (GET, POST, PUT, DELETE) с явной семантикой
• Простой контракт, легко отладить
• Де-факто стандарт для публичных API

Когда применять: публичные API, операции требующие немедленного результата.

gRPC

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

• RPC поверх HTTP/2, использует Protocol Buffers для сериализации
• Типобезопасный контракт, сгенерированные клиенты и сервера
• Меньше payload'а за счёт бинарной сериализации
• Лучше для высокочастотного inter-service трафика

Расчёт экономии: REST-запрос с JSON может весить 500 байт, тот же запрос в gRPC с protobuf — 100–150 байт. При 100 000 RPS экономия составляет примерно 350 Мбит/с.

Когда применять: микросервисное взаимодействие, high-throughput API, системы требующие низкой задержки.

GraphQL

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

• Язык запросов, позволяющий клиенту запросить ровно нужные поля
• Решает проблемы over-fetching (лишние данные) и under-fetching (нужны данные из нескольких API)
• Более сложен в реализации

Когда применять: мобильные клиенты (экономия трафика), разнородные фронтенд-клиенты с разными потребностями.

Плюсы синхронных вызовов

• Простота: отправил запрос, получил ответ, операция завершена
• Предсказуемая модель обработки ошибок
• Подходит для операций требующих немедленный результат (пользователь видит ответ на экране)

Минусы синхронных вызовов

Каскадные сбои: если сервис B недоступен, и A синхронно вызывает B, то A не может ответить. Если C вызывает A, то C тоже не может ответить. Цепочка накрывается.

Умножение задержки: запрос A → B → C с задержкой 20 мс на каждый скачок требует 60 мс (плюс обработка).

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

Асинхронные паттерны

Очереди и брокеры сообщений

Вместо синхронного вызова сервис отправляет сообщение в очередь. Другой сервис подписывается на очередь и обрабатывает асинхронно.

Популярные реализации:

• RabbitMQ (message broker с queues и topics)
• Apache Kafka (distributed event streaming)
• AWS SQS (облачная очередь)
• Redis Streams (simple очереди в памяти)

Event-driven архитектура

Система состоит из независимых компонентов, реагирующих на события.

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

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

Каждый сервис обрабатывает независимо, не зная о существовании других.

Плюсы асинхронных взаимодействий

• Декаплинг: сервисы независимы, не знают друг о друге
• Отказоустойчивость: если потребитель недоступен, сообщение остаётся в очереди, обработается позже
• Буферизация нагрузки: пики трафика сглаживаются за счёт очереди
• Масштабирование: легко добавить параллельных обработчиков
• Нет retry storm'а: если задача не получилась, она ретраится внутри очереди, не создавая дополнительный трафик к зависимому сервису

Минусы асинхронных взаимодействий

• Eventual consistency: данные согласованы не сразу, а со временем
• Сложность отладки: ошибка может проявиться через час после отправки сообщения
• Обязательная идемпотентность: сообщение может быть обработано несколько раз из-за гарантий доставки
• Dead Letter Queue и мониторинг: нужны механизмы обработки ошибок и отслеживания потеринного трафика

Выбор между синхронным и асинхронным

Используй синхронные вызовы:

• Когда нужен немедленный результат (пользователь видит ответ)
• Короткие цепочки (максимум 2–3 вызова)
• Low-latency операции

Переходи на асинхронные:

• Когда операция может быть обработана позже (отправка писем, обработка файлов)
• Долгие операции (риск таймаутов)
• Высоконагруженные системы нуждаются в буферизации
• Нужна отказоустойчивость к сбоям зависимых сервисов

Гибридный подход: критичные операции обрабатываются синхронно с коротким таймаутом, фоновая работа идёт в очередь.

Путь запроса от клиента до backend-сервиса

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

Клиент 
  ↓ (DNS)
Балансировщик L4 (DDoS protection)
  ↓
Балансировщик L7 / API Gateway (аутентификация, rate limiting)
  ↓
Backend-сервисы (обработка бизнес-логики)
  ↓
Кеши (Redis), БД (PostgreSQL), очереди (Kafka)

Роль каждого компонента

DNS

Преобразует доменное имя (example.com) в IP-адрес. Может возвращать несколько адресов в round-robin режиме или на основе географического расположения клиента.

CDN (Content Delivery Network)

Сеть серверов, расположенных географически близко к пользователям, кеширующая статический контент:

• Картинки, CSS, JavaScript
• Видеофайлы
• Шрифты

Примеры: Cloudflare, Akamai, AWS CloudFront, Yandex.Cloud CDN.

Расчёт экономии: если 30% трафика — статический контент (видео, картинки), и с CDN задержка снижается с 200 мс до 20 мс, то для пользователя средняя задержка страницы снижается примерно на 5% (не 30%, так как статический контент не всегда критичен).

WAF (Web Application Firewall)

Фильтрует malicious трафик на уровне HTTP.

Защита от:

• SQL injection
• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• DDoS на L7

Балансировщик L4 (Layer 4)

Распределяет трафик на основе IP-адреса и портов.

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

• Видит только адреса и порты, не смотрит в содержимое
• Очень производительный
• Используется перед несколькими L7-proxy'ями для первичного распределения

Балансировщик L7 / Reverse Proxy / API Gateway

Смотрит на HTTP-уровне: заголовки, URL, методы.

Функции:

• Маршрутизация по URL-пути: /api/users/* → сервис users
• Версионирование API: /v1/… vs /v2/…
• Аутентификация (JWT, API ключи)
• Rate limiting
• Логирование
• Трансформация запросов

Backend-сервисы

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

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

L4 Load Balancer

Что видит: IP-адрес отправителя, IP-адрес получателя, порт, протокол (TCP/UDP).

Алгоритм работы: получает пакет, выбирает один из backend-серверов по алгоритму, перенаправляет пакет туда.

Плюсы:

• Производительность: очень быстро
• Универсальность: работает с любым протоколом
• Простота реализации

Минусы:

• Тупой роутинг: не видит содержимое
• Неоптимальное распределение, если серверы разной мощности

L7 Load Balancer / Reverse Proxy

Что видит: всё что L4, плюс HTTP метод, URL path, query параметры, headers, cookies, body.

Возможности:

• Умный роутинг (по URL, headers, версии)
• Модификация запросов
• Content-based switching

Минусы:

• Более затратно по CPU
• Может быть узким местом при очень высоких нагрузках

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

Round Robin

Запросы распределяются по очереди: 1-й на сервер 1, 2-й на сервер 2, 3-й на сервер 3, затем снова на 1.

Плюсы: простейший, справедливое распределение при одинаковых серверах.

Минусы: не учитывает текущую нагрузку на сервер.

Weighted Round Robin

Каждому серверу назначен вес на основе мощности.

Пример: сервер 1 (вес 3), сервер 2 (вес 1). Из 4 запросов: 3 на сервер 1, 1 на сервер 2.

Least Connections / Least Outstanding Requests

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

Когда помогает: если запросы имеют очень разное время обработки.

Random с двумя вариантами (Power of Two Choices)

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

Преимущество: снижает дисперсию нагрузки по сравнению с чистым random, дешевле чем fully optimal.

IP Hash / Session Affinity

Хеширование IP-адреса клиента определяет целевой сервер.

Плюсы: все запросы клиента идят на один сервер, переиспользуется local cache сессии.

Минусы: неравномерное распределение, при падении сервера клиент потеряет сессию.

Consistent Hashing

Используется в распределённых кешах (Redis Cluster) и хранилищах (Cassandra).

Идея: каждому серверу и ключу назначается позиция на hash ring. Ключ идёт на ближайший сервер по кругу.

Преимущество: при добавлении/удалении сервера, большинство ключей остаются на месте. Без consistent hashing'а добавление одного сервера перераспределило бы все ключи.

Расчёт: 3 сервера, 1000 ключей. Добавляешь 4-й сервер.

• Без consistent hashing: переехали бы 750 ключей (75%)
• С consistent hashing: переехали бы 250 ключей (25%)

Health-check'и и управление пулом инстансов

Active Health Checks

LB периодически отправляет запрос каждому backend-серверу.

Параметры:

• Интервал проверки: 10 секунд
• Таймаут: 2 секунды
• Количество неудачных проверок для исключения: 2–3 подряд

Пример: HTTP GET на /health возвращает 200 OK с JSON:

{"status": "healthy"}

Passive Health Checks

LB отслеживает ошибки реальных запросов (5xx, таймауты). После нескольких ошибок сервер исключается.

Преимущество: не требует отдельных запросов.

Недостаток: может быть задержка накопления ошибок.

Статусы инстанса

• Healthy: запросы идут на этот сервер
• Unhealthy: новые запросы не идут, но мониторинг продолжается
• Draining: новые запросы не идят, активные запросы доводятся до конца (graceful shutdown)
• Возврат: когда health-check'и проходят, сервер возвращается в пул

Sticky Sessions (Session Affinity): проблемы и решения

Определение

Sticky sessions — когда запросы от одного клиента всегда идят на один и тот же backend-сервер. Появляются в stateful приложениях, где session-данные хранятся в памяти сервера.

Способы реализации

IP hash: LB хеширует IP-адрес, результат определяет сервер.

Cookie-based: LB устанавливает cookie (например, X-LB-Session: server-3), клиент отправляет её в запросах.

Проблемы sticky sessions

Неравномерная нагрузка: если один клиент генерирует много трафика, весь его трафик идёт на один сервер, создавая hot spot.

Потеря данных при сбое: если сервер с session-данными упадёт, клиент потеряет сессию.

Сложность масштабирования: нельзя просто добавить сервер и ожидать равномерное распределение.

Рекомендуемый подход: stateless архитектура

Лучшее решение: избегать sticky sessions, используя stateless-архитектуру.

Реализация:

• Session-данные (user ID, permissions, cart) хранятся в Redis или другом external store
• Каждый backend-сервер может обслуживать каждого клиента
• При падении сервера данные не теряются

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

• Равномерное распределение нагрузки
• Быстрое добавление/удаление серверов
• Отказоустойчивость

TLS-терминация и внутренний трафик

TLS Termination на Edge

Модель:

1. Клиент отправляет HTTPS-запрос → edge LB расшифровывает (TLS termination)
2. Внутри кластера трафик идёт plain HTTP (если trusted сеть) или по mTLS
3. Ответ идёт обратно

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

• Backend-сервисы не тратят CPU на шифрование
• Централизованное управление сертификатами
• LB может видеть HTTP-content и применять правила

mTLS (Mutual TLS) внутри кластера

Назначение: обе стороны аутентифицируют друг друга через сертификаты.

Когда требуется:

• High-security окружения (финансовые системы, healthcare)
• Multi-tenant архитектура, требующая гарантии аутентификации сервиса
• Compliance требования (PCI DSS, HIPAA)

Реализация: обычно через service mesh (Istio, Linkerd), который управляет mTLS автоматически.

Горизонтальное масштабирование с помощью балансировщиков

Архитектура

Все backend-инстансы stateless. Перед ними стоит load balancer (или несколько для HA). При возрастании нагрузки добавляются новые инстансы, LB начинает маршрутить на них.

Ручное и автоматическое масштабирование

Ручное: DevOps добавляет инстанс в конфиг LB.

Автоматическое (autoscaling):

• Система мониторит метрики (CPU, memory, RPS)
• При превышении threshold'а автоматически запускаются новые инстансы
• Они регистрируются в пуле LB
• При снижении нагрузки инстансы shutdownятся

Требования для autoscaling:

• Orchestration (Kubernetes, Nomad)
• Metrics collection (Prometheus, InfluxDB)
• Autoscaler (Kubernetes HPA, custom скрипт)

Многоуровневая балансировка

Для региональных систем:

Клиент
  ↓ (Global load balancer)
Global LB маршрутит в регион (US, EU, APAC)
  ↓ (Regional load balancer)
Regional LB выбирает зону (us-east-1, us-west-2)
  ↓ (Zonal load balancer или service discovery)
Backend-инстансы в зоне

Edge-паттерны: защита и управление трафиком

Rate Limiting и Throttling

Rate limiting — ограничение количества запросов от клиента за единицу времени.

Зачем:

• Защита от DDoS: каждый бот может отправить только N запросов/сек
• Защита от broken клиентов (приложение баговано, спамит)
• Управление нагрузкой при перегрузке системы

Алгоритмы:

Token Bucket: у клиента есть "ведёрко" токенов. Каждый запрос тратит один токен. Токены пополняются со временем.

• Лимит: 100 запросов в секунду
• Максимум в "ведёрке": 100 токенов
• Пополнение: 100 токенов/сек
• Всплески: если система была простаивает, накопилось 100 токенов, клиент может отправить 100 запросов сразу

Sliding Window: считаем запросы за последние N секунд. Если больше лимита — отбиваем.

Leaky Bucket: запросы идят в очередь, обрабатываются с фиксированной скоростью, лишние отбиваются.

Где реализуется: обычно на API gateway или edge LB. Можно также на уровне приложения, но на edge эффективнее.

WAF (Web Application Firewall)

Фильтрует HTTP-трафик на основе правил.

Защита от:

• SQL Injection
• XSS (Cross-Site Scripting)
• CSRF (Cross-Site Request Forgery)
• DDoS на L7 (flood attacks)

API Gateway

Центральная точка входа для всех API-запросов.

Функции:

Сетевые ошибки, таймауты и ретраи

Виды сбоев

Таймауты: запрос долго обрабатывается, клиент дает таймаут. Причины: перегрузка backend'а, зависание процесса, сетевая задержка.

Connection Reset: соединение разорвалось посередине. Причины: потеря пакетов, firewall, crash backend'а.

Partial Failures: один сервис в цепочке синхронных вызовов недоступен. Запрос A → B → C, B упал. A видит ошибку и возвращает её клиенту.

Ретраи и стратегии

Когда ретраить:

• Таймауты (возможно временная перегрузка)
• Connection reset (может быть временная проблема)
• 503 Service Unavailable
• 429 Too Many Requests (rate limit)

Когда не ретраить:

• 4xx ошибки (Bad Request, Unauthorized, Forbidden)
• POST-запросы без idempotency guarantee

Backoff-стратегии

Линейный backoff: 1 сек, 2 сек, 3 сек, 4 сек…

Экспоненциальный backoff: 1 сек, 2 сек, 4 сек, 8 сек, 16 сек…

Экспоненциальный лучше: если backend перегружен, не забиваем его множеством ретраев, даём время восстановиться.

Максимальная задержка: обычно 30–60 сек, чтобы не ждать вечность.

Джиттер (Jitter)

Добавляет случайную задержку к backoff'у, предотвращая synchronized retry storm (когда все клиенты ретраят в одно время).

Пример: вместо строго 2 сек, ретраим в 1.5–2.5 сек. Это разреживает ретраи по времени.

Retry Storm

Проблема: когда backend перегружен, все клиенты начинают ретраить, это перегружает backend ещё больше, создаётся positive feedback loop.

Решение: exponential backoff + jitter + circuit breaker (при многих ошибках просто отказываем клиенту вместо ретраев).

Идемпотентность (Idempotency)

Определение: операция идемпотентна, если вызов её несколько раз даёт тот же результат, что один раз.

Идемпотентные операции:

• GET (не меняет состояние)
• Создание ресурса с unique ID (повторное создание игнорируется или возвращает существующий)
• DELETE (удаление уже удаленного — 404, но не критично)

Не идемпотентные:

• Перевод денег (ретрай переведёт дважды)
• Инкремент счетчика (каждый ретрай увеличит на 1)

Реализация идемпотентности:

1. Добавить unique request ID (idempotency key) в заголовок
2. На сервере сохранять результат последнего запроса с этим ID
3. Если приходит повторный запрос с тем же ID, возвращаем сохранённый результат (не переэкзекутируем)

Пример:

POST /transfer
Idempotency-Key: abc123-def456

Request #1: Сервер выполняет трансфер, сохраняет результат
Request #2 (ретрай с тем же ключом): Сервер возвращает старый результат без переэкзекуции

Хранилище результатов: Redis с TTL (keep для нескольких часов) или database.

Сетевое взаимодействие в Java backend

Connection Pools

Проблема: каждое соединение требует 3-way handshake (~30 мс) + TLS handshake (~20 мс) = 50 мс на соединение. Если создавать новое для каждого запроса, половина времени тратится на setup.

Решение: переиспользовать соединения в пуле.

Параметры:

• Min pool size: 5–10 соединений
• Max pool size: 20–100 (в зависимости от нагрузки)
• Connection timeout: как долго ждать свободное соединение
• Idle timeout: через сколько закрыть неиспользуемое соединение (обычно 5–10 минут)

Таймауты

Connect timeout: ожидание установления TCP-соединения. Обычно 2–5 сек.

Read timeout: ожидание ответа после отправки запроса. Обычно 5–30 сек (зависит от операции).

Write timeout: ожидание готовности соединения к отправке. Обычно 2–5 сек.

Важность: без таймаутов запрос может зависнуть на бесконечность, thread pool заполнится, система упадёт.

Thread Pool и параллелизм

Обработка каждого запроса выполняется в потоке. Thread pool имеет:

• Core size: обычно = количество CPU ядер
• Max size: 100–500
• Queue: очередь ожидающих задач

Связь с сетью: если thread pool из 50 потоков и каждый делает синхронный запрос с таймаутом 10 сек, система может обслуживать примерно 5 RPS при максимальной утилизации.

Расчёт: max_rps = pool_size / request_latency = 50 / 10 = 5 RPS.

Решение для high-concurrency: асинхронные фреймворки (Vert.x, Spring WebFlux, Kotlin coroutines), которые не привязывают потоки к соединениям.

Пример конфигурации на Java

// HTTP-клиент с pool'ом и таймаутами
HttpClient httpClient = HttpClient.newBuilder()
  .connectTimeout(Duration.ofSeconds(2))
  .build();

// Или с Apache HttpClient
RestTemplate restTemplate = new RestTemplate(
  new HttpComponentsClientHttpRequestFactory(
    HttpClientBuilder.create()
      .setConnectionManager(poolingConnectionManager)
      .setDefaultRequestConfig(
        RequestConfig.custom()
          .setConnectTimeout(2000)
          .setSocketTimeout(5000)
          .build()
      )
      .build()
  )
);

Практический пример архитектуры с расчётами

Система: платформа для обработки видео

Требования:

• 10 000 одновременных пользователей
• Каждый пользователь загружает видео (средний размер 500 МБ)
• Обработка: кодирование в 3 формата (720p, 480p, 240p)
• Результат доставляется через CDN

Расчёт нагрузки

Входящий трафик:

• 10 000 пользователей × 500 МБ среднего размера / 3600 сек (в течение часа) = 1388 МБ/сек = 11 Гбит/сек
• Требуемая пропускная способность с запасом: 15 Гбит/сек

Backend-обработка:

• Задач в очереди: 10 000 ÷ 60 = примерно 167 видео обрабатывается одновременно (при среднем времени обработки 1 часа)
• Если сервер кодирует 1 видео за час, нужно ~167 воркеров или машин для параллельной обработки

Хранилище результатов:

• Трёхформатное видео: исходное (500 МБ) + 3 версии обычно 50–70% от исходного = 500 + 3×300 = 1400 МБ
• За 10 000 загрузок: 10 000 × 1.4 ГБ = 14 ТБ

CDN доставка:

• Статистика: 30% пользователей смотрят видео дважды (rewatch rate)
• Примерно 13 000 view'ов в час от 10 000 пользователей
• При среднем размере видео 300 МБ (одной версии) = 13 000 × 300 МБ / 3600 сек = 1083 МБ/сек = 8.7 Гбит/сек
• CDN значительно снижает нагрузку на origin (может быть 90%+ cache hit rate)

Выбор технологий

Intake (приём видео):

• L4 LB перед несколькими reverse proxy'ями
• Reverse proxy с rate limiting (max 100 МБ/сек на пользователя)
• Direct upload на S3 или похожее хранилище

Обработка:

• Асинхронная очередь (Kafka или RabbitMQ)
• 167+ воркеров (можно в Kubernetes контейнерах с autoscaling)
• Воркер: ffmpeg для кодирования

Доставка:

• CDN (Cloudflare, Akamai) — 90% трафика идёт туда
• Origin: S3 или собственный object storage с LB

Сообщения между компонентами:

• REST API для управления (создание задач, проверка статуса)
• gRPC или internal events для синхронизации между воркерами и storage

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

• Redis для метаданных видео (title, description, views count)
• TTL: 1 день для часто смотрящихся видео, 1 час для менее популярных

Сводная таблица выбора технологий и подходов

Аналоги инструментов и технологий

Ключевые принципы сетевой архитектуры

1. Минимизация latency: избегай длинных цепочек синхронных вызовов, используй асинхронность где возможно.

2. Избыточность на каждом уровне: multiple LB'ы, multiple backend'ы, multiple replicas в БД, multiple зоны доступности.

3. Graceful degradation: если часть системы упала, остаток продолжает работать. Используй timeouts, ретраи, fallback'и.

4. Мониторинг и observability: отслеживай latency, error rates, throughput на каждом уровне. Используй распределённый трейсинг (Jaeger, Zipkin).

5. Кеширование на каждом уровне: browser cache (HTTP headers), CDN cache, application cache (Redis), query cache в БД. Но избегай stale data.

6. Stateless architecture: сервисы не хранят state, state в external store (Redis, БД). Позволяет масштабировать горизонтально.

7. Правильный выбор протокола: REST для simplicity, gRPC для performance, WebSocket для real-time, SSE для simpler real-time.

8. Idempotency by default: все операции изменения должны быть идемпотентны (или иметь механизм идемпотентности).

Расчётные примеры и формулы

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

[\text{Required Bandwidth} = \text{RPS} \times \text{Average Request Size (bytes)} \times 8 / 1,000,000,000]

Пример: 50 000 RPS × 2 КБ × 8 / 1 млрд = 0.8 Гбит/с

Время на соединение

[\text{Total Connection Time} = 3 \times \text{RTT} + 2 \times \text{RTT}_{\text{TLS}} = 5 \times \text{RTT}]

При RTT = 10 мс: 50 мс на установление защищённого соединения

Capacity по thread pool'е

[\text{Max RPS} = \frac{\text{Thread Pool Size}}{\text{Average Request Latency (seconds)}}]

Пример: 100 потоков / 0.1 сек (100 мс) = 1000 RPS при 100% утилизации

Exponential backoff

[\text{Delay}_n = \text{Base Delay} \times 2^n + \text{Jitter}]

Пример: Base = 1 сек, попытка 1 = 2 сек, попытка 2 = 4 сек, попытка 3 = 8 сек (+ случайная jitter)

Consistent hashing — переезд ключей при добавлении сервера

[\text{Keys to Move} = \frac{\text{Total Keys}}{\text{Old Server Count} + 1}]

Пример: 1000 ключей, было 3 сервера, добавили 4-й: 1000 / 4 = 250 ключей переехали (25%)

Дополнительные ресурсы для углубления

Ключевые концепции для изучения

1. TCP/IP stack — как работает transport layer
2. Congestion control (TCP Reno, CUBIC) — как сеть избегает перегрузок
3. BGP и routing — как данные находят путь через интернет
4. Load balancing алгоритмы — power of two, consistent hashing, ECMP
5. Observability — distributed tracing (Jaeger), metrics (Prometheus), logs (ELK)
6. Chaos engineering — тестирование отказоустойчивости (введение latency, потери пакетов)
7. Software-Defined Networking (SDN) — контроль трафика на уровне приложения

Практическое применение

• Написать простой load balancer на Go/Java с round-robin и health-check'ами
• Настроить Nginx как reverse proxy с multiple backend'ами
• Протестировать timeout и retry поведение с tools вроде tc (traffic control) для эмуляции задержек
• Использовать distributed tracing (Jaeger) для анализа inter-service вызовов

Проектирование API

Роль проектирования API в распределённых системах

API — это граница между компонентами распределённой системы. Плохо спроектированное API приводит к хрупкости: любое изменение требует синхронизации множества команд, появляются циклические зависимости, растёт количество ошибок при интеграции.

Качественный API обеспечивает:

• независимую и параллельную работу команд;
• упрощённую отладку через чёткие контракты;
• эволюцию системы без ломающих изменений;
• слабую связанность между сервисами.

Внешние (public) vs внутренние (internal) API

Внешние API (клиенты за пределами компании):

• максимальная стабильность и обратная совместимость;
• осторожное версионирование с поддержкой 2–3 версий;
• строгая документация (OpenAPI/Swagger);
• отказоустойчивость к разным типам клиентов и сетевым условиям.

Внутренние API (микросервисы):

• быстрое обновление (все сервисы в одной системе);
• эффективные форматы (gRPC, бинарные протоколы);
• контрактная разработка (contract-first);
• идемпотентность с логикой восстановления на уровне инфраструктуры.

REST API: ресурсно-ориентированный дизайн

Концепция ресурса

Ресурс — это абстракция сущности, которой присваивается уникальный идентификатор (URI). С ресурсом работают через стандартные HTTP-методы, а не через глаголы в URL.

Преимущества подхода:

• кеширование на уровне HTTP (GET безопасен, PUT/DELETE идемпотентны);
• знакомый паттерн, упрощающий разработку;
• разделение логики контроллера и бизнес-логики;
• использование стандартных фреймворков и инструментов мониторинга.

Моделирование ресурсов и связей

Базовые сущности:

/users — коллекция пользователей
/users/{id} — конкретный пользователь
/orders — коллекция заказов
/orders/{id} — конкретный заказ

Вложенные ресурсы:

/users/{userId}/orders — заказы конкретного пользователя
/orders/{orderId}/items — позиции в заказе

Вложенные ресурсы подходят для отношений «один-ко-многим» до 2–3 уровней глубины. При большей глубине используйте отдельные вызовы с фильтрацией:

// Правильно (глубина 2):
/users/{userId}/orders/{orderId}/items

// Плохо (глубина 3+):
/users/{userId}/orders/{orderId}/items/{itemId}/reviews

// Лучше:
/items?orderId={orderId}
/reviews?itemId={itemId}

Связи через идентификаторы:

Для больших систем возвращайте только идентификатор, а не вложенный объект:

{
  "id": "ord123",
  "userId": "user456",
  "amount": 99.99
}

или с явным указанием связи:

{
  "id": "ord123",
  "links": {
    "user": "/users/user456"
  },
  "amount": 99.99
}

Именование и структура URL

Правило: используйте существительные во множественном числе

✓ /users, /orders, /payments
✗ /getUsers, /createOrder, /deletePayment

Действие (глагол) кодируется в HTTP-методе, а не в URL. Исключение — нестандартные действия:

POST /orders/{id}:cancel
POST /payments/{id}:refund

Лучше спроектировать как отдельный ресурс:

POST /orders/{id}/cancellations

Иерархия URL отражает иерархию данных, но не создавайте искусственные иерархии:

// Правильно:
GET /orders/{orderId}
GET /orders?userId=user456

// Неправильно:
GET /users/{userId}/orders/{orderId}/status
// Вместо этого: GET /orders/{orderId} и вернуть всё, включая статус

Параметры запроса (query parameters):

GET /orders?userId=user456&status=pending&limit=20&offset=0
GET /users?name=John&createdAfter=2025-01-01

Параметры используются для фильтрации, пагинации, сортировки, а не для идентификации ресурса. Параметры опциональны.

HTTP-методы и семантика

GET: Не меняет состояние. Может кешироваться. Повторный вызов даёт тот же результат.

POST: Создание нового ресурса. Ответ обычно 201 Created с заголовком Location и телом с созданным ресурсом.

PUT: Полное обновление или создание ресурса. Повторный вызов с той же сущностью не меняет результат на сервере.

PATCH: Частичное обновление. PATCH может быть неидемпотентен в зависимости от операции (например, {"counter": "+1"}).

DELETE: Удаление ресурса. Повторное удаление несуществующего ресурса должно вернуть 204 или 404.

Статус-коды и обработка ошибок

Основные группы статус-кодов

2xx — успех:

• 200 OK — запрос выполнен, данные в теле ответа;
• 201 Created — ресурс создан, Location указывает на новый ресурс;
• 202 Accepted — запрос принят, обработка асинхронна;
• 204 No Content — успех без тела ответа.

4xx — ошибка клиента:

• 400 Bad Request — синтаксическая ошибка в запросе;
• 401 Unauthorized — требуется аутентификация;
• 403 Forbidden — нет прав доступа;
• 404 Not Found — ресурс не найден;
• 409 Conflict — конфликт состояния;
• 422 Unprocessable Entity — данные валидны синтаксически, но семантически некорректны.

5xx — ошибка сервера:

• 500 Internal Server Error — непредвиденная ошибка;
• 502 Bad Gateway — промежуточный прокси не может соединиться с upstream-сервисом;
• 503 Service Unavailable — сервис недоступен;
• 504 Gateway Timeout — сервис не ответил за отведённое время.

Консистентный формат ошибок

{
  "code": "INSUFFICIENT_FUNDS",
  "message": "Not enough funds in the account",
  "details": {
    "balance": 50.00,
    "required": 150.00,
    "currency": "USD"
  },
  "traceId": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2025-11-27T12:00:00Z"
}

Поля:

• code — постоянный идентификатор ошибки для автоматической обработки;
• message — понятное описание;
• details — дополнительный контекст;
• traceId — для отслеживания в логах;
• timestamp — время возникновения.

Для ошибок валидации:

{
  "code": "VALIDATION_ERROR",
  "message": "Invalid request parameters",
  "details": {
    "errors": [
      {"field": "email", "message": "Invalid email format"},
      {"field": "age", "message": "Must be >= 18"}
    ]
  },
  "traceId": "550e8400-e29b-41d4-a716-446655440000"
}

Контракты и структура данных

Структура JSON и Protobuf сообщений

Стабильные поля:

{
  "id": "ord123",
  "userId": "user456",
  "amount": 99.99,
  "currency": "USD",
  "createdAt": "2025-11-27T10:00:00Z"
}

Ядро контракта не должно меняться в течение жизни версии API.

Добавление новых полей:

{
  "id": "ord123",
  "userId": "user456",
  "amount": 99.99,
  "currency": "USD",
  "createdAt": "2025-11-27T10:00:00Z",
  "status": "pending",
  "estimatedDelivery": "2025-11-30T23:59:59Z"
}

Старые клиенты проигнорируют новые поля. Новые клиенты смогут их использовать. Это backward-compatible изменение.

Nullable vs обязательные поля:

message Order {
  string id = 1;
  string user_id = 2;
  double amount = 3;
  optional string shipping_address = 4;
  optional string notes = 5;
}

Консистентность контрактов между сервисами

Единый стиль полей: выберите одну конвенцию и придерживайтесь её везде

• camelCase (популярно в Java мире);
• snake_case (популярно в Python мире).

Соглашения по датам: всегда используйте ISO 8601

✓ 2025-11-27T12:00:00Z
✓ 2025-11-27T12:00:00+03:00
✗ 2025-11-27 12:00:00 (неправильный формат)
✗ 27.11.2025 12:00 (locale-specific)
✗ 1732694400 (Unix timestamp без контекста)

Соглашения по деньгам: передавайте сумму в основных единицах (доллары, евро) с фиксированной точностью

{
  "amount": 99.99,
  "currency": "USD"
}

или всегда в центах (целое число):

{
  "amountCents": 9999,
  "currency": "USD"
}

Соглашения по идентификаторам:

• UUID: 550e8400-e29b-41d4-a716-446655440000 (стабильно, не раскрывает количество);
• autoincrement: 12345 (короче, но раскрывает информацию);
• custom prefix: ord_123456 (читаемо, указывает на тип).

Документирование контрактов

OpenAPI для REST:

openapi: 3.0.0
info:
  title: Order Service API
  version: 1.0.0

paths:
  /orders:
    get:
      parameters:

        - name: limit
          in: query
          schema:
            type: integer
            default: 10
      responses:
        '200':
          description: List of orders
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Order'

Protobuf для gRPC:

syntax = "proto3";

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc ListOrders(ListOrdersRequest) returns (ListOrdersResponse);
}

message Order {
  string id = 1;
  string user_id = 2;
  double amount = 3;
  google.protobuf.Timestamp created_at = 4;
}

Идемпотентность и надёжность операций

Определение идемпотентности

Идемпотентность — свойство операции, при котором повторный вызов с теми же параметрами даёт тот же результат, что и первый вызов.

Идемпотентно:   PUT /users/{id} с сущностью {name: "Alice"}
Не идемпотентно: POST /transfers с {from: acc1, to: acc2, amount: 100}
                 (первый вызов переводит 100, второй — ещё 100)

Почему идемпотентность критична в распределённых системах

• Сетевые сбои: клиент отправил запрос, но не получил ответ (timeout). Не зная, обработан ли запрос, клиент повторяет. Если операция идемпотентна, безопасно повторить.

• Восстановление инфраструктуры: Kubernetes может перезагрузить pod в середине обработки, балансировщик может перенаправить запрос на другой инстанс. Если операция идемпотентна, система восстановится.

• Гарантии доставки: сложнее гарантировать ровно один раз. Идемпотентность — более достижимый идеал.

Примеры идемпотентных операций

PUT с фиксированным ID:

PUT /users/{id}
{ "name": "Alice", "email": "alice@example.com" }

Первый запрос создаёт или обновляет пользователя. Повторный запрос заменяет пользователя теми же данными — результат идентичен.

POST с идемпотентным ключом (idempotency key):

POST /transfers
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

{ "from": "acc1", "to": "acc2", "amount": 100.00 }

Клиент генерирует уникальный идентификатор и отправляет его в заголовке Idempotency-Key. Сервер сохраняет ключ и результат. При повторном запросе с тем же ключом сервер возвращает кешированный результат.

DELETE:

DELETE /users/{id}

Первый вызов удаляет пользователя. Повторный вызов — ресурс уже удалён, вернуть 204 или 404. Итоговое состояние одинаковое.

Реализация идемпотентности

Сохранение результата:

Сервер поддерживает таблицу (или кеш в Redis):

| Idempotency-Key                      | Status | Response          |
|--------------------------------------|--------|-------------------|
| 550e8400-e29b-41d4-a716-446655440000| 200    | {"transferId":"tr123"} |

При повторном запросе с тем же ключом сервер находит результат и возвращает его без повторной обработки.

На уровне базы данных:

Composite unique key:

CREATE UNIQUE INDEX idx_order_payment ON payments(order_id, external_payment_ref);

Попытка повторного вставления вызывает ошибку, которую можно обработать как "уже обработано".

Синхронная и асинхронная коммуникация между микросервисами

Выбор стиля связи

REST/JSON (синхронная):

Order Service → GET /api/users/{userId} → User Service

Плюсы:

• знакомо большинству разработчиков;
• легко отлаживать (HTTP, curl/Postman);
• HTTP-статус-коды соответствуют состоянию.

Минусы:

• требует одновременной доступности обоих сервисов;
• latency кумулируется;
• сложнее обеспечить идемпотентность.

gRPC/Protobuf (синхронная, эффективная):

service UserService {
  rpc ValidateUser(ValidateUserRequest) returns (ValidateUserResponse);
}

Плюсы:

• компактные бинарные сообщения (меньше network overhead);
• двунаправленный стриминг;
• строгая типизация;
• лучше для high-throughput.

Минусы:

• генерируемый код, требует обновления при изменении proto;
• сложнее отлаживать;
• требует HTTP/2;
• требует специализированной библиотеки клиента.

События (асинхронные):

Order Service → publish OrderCreated → message broker → User Service subscribes

Плюсы:

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

Минусы:

• асинхронность (труднее отлаживать);
• eventual consistency;
• требует обработки дублирующихся сообщений.

Слабая связанность через API

Минимизация необходимых полей:

// Плохо (излишняя информация):
{
  "id": "ord123",
  "user": {
    "id": "user456",
    "name": "Alice",
    "email": "alice@example.com",
    "phone": "+1234567890",
    "address": { /* полный адрес */ }
  }
}

// Хорошо (только необходимое):
{
  "id": "ord123",
  "userId": "user456",
  "amount": 99.99
}

Отделение внутренних моделей от внешних DTO:

Внутренняя модель может содержать пароли и временные данные. При возврате через API используйте DTO, содержащий только публичные поля.

gRPC и бинарные протоколы

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

gRPC — фреймворк для удалённых вызовов (RPC) поверх HTTP/2 с использованием Protobuf. Используется для синхронной коммуникации между сервисами при высокой пропускной способности и низкой latency.

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

Компактность сообщений:

Protobuf использует бинарный формат:

JSON:  {"id":"123","name":"Alice","email":"alice@ex.com"} ≈ 50 bytes
Proto: (то же самое) ≈ 20 bytes

При большом количестве запросов это значительно снижает сетевой трафик.

Строгая типизация:

Proto-файлы — единый источник правды. Генерируются Java/Go/Python классы, исключающие ошибки типизации.

Типы коммуникации:

1. Unary — простой запрос-ответ
2. Server streaming — сервер отправляет поток
3. Client streaming — клиент отправляет поток
4. Bidirectional streaming — обе стороны одновременно отправляют и получают

Недостатки gRPC

• Требует специализированного клиента (не работает в браузере);
• генерируемый код, требует обновления при изменении proto;
• требует HTTP/2;
• сложнее отлаживать.

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

• Внутренняя микросервисная коммуникация с требованиями по latency;
• high-throughput, low-latency сценарии;
• полиглотная среда с требованиями к типизации.

Когда не использовать:

• Публичные API (используйте REST);
• когда нужна простота и отладка;
• когда клиенты внешние (браузеры, мобильные без специальной поддержки).

Версионирование API и эволюция контрактов

Зачем нужно версионирование

API постоянно меняется. Версионирование позволяет:

• развивать API без ломания старых клиентов;
• постепенно мигрировать на новые версии;
• поддерживать 2–3 версии одновременно.

Стратегии версионирования

1. Версионирование в пути (URL path versioning):

GET /v1/users/{id}
GET /v2/users/{id}

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

2. Версионирование через заголовки:

GET /users/{id}
Accept: application/vnd.example.v2+json

или

GET /users/{id}
X-API-Version: 2

Плюсы: URL остаётся чистым. Минусы: менее очевидно при отладке.

3. Content negotiation:

GET /users/{id}
Accept: application/vnd.example.v2+json

Стандартный подход IETF.

Backward-compatible vs breaking changes

Backward-compatible (безопасные):

• Добавление новых опциональных полей;
• добавление новых значений в enum;
• добавление новых опциональных параметров запроса;
• добавление новых эндпоинтов;
• удаление deprecated полей после предупреждения.

Breaking changes (опасные):

• Переименование или удаление существующего поля;
• изменение типа поля;
• изменение структуры;
• изменение семантики.

Подход "expand-only" для внутренних контрактов

Если вы контролируете оба конца API, используйте "expand-only": никогда не переименовывайте и не удаляйте поля, только добавляйте новые.

// v1
message User {
  string id = 1;
  string name = 2;
  string email = 3;
}

// v2 (expand-only)
message User {
  string id = 1;
  string name = 2;
  string email = 3;
  string status = 4;     // только добавляем
  string phone = 5;      // только добавляем
  // никогда не удаляем старые поля
}

Это работает, потому что:

• старые клиенты игнорируют новые поля;
• новые клиенты могут их использовать;
• не нужно поддерживать несколько версий proto.

Пагинация, фильтрация, сортировка

Пагинация

Limit/Offset:

GET /orders?limit=10&offset=0
GET /orders?limit=10&offset=10
GET /orders?limit=10&offset=20

Плюсы: просто реализовать, интуитивно понимается, можно прыгнуть на любую страницу.

Минусы: если данные вставляются/удаляются, может быть дублирование или пропуски; медленна на больших offset (full table scan).

Cursor-based:

GET /orders?limit=10&cursor=null
GET /orders?limit=10&cursor=ord_00010
GET /orders?limit=10&cursor=ord_00020

Плюсы: стабильна при вставках/удалениях, эффективна на больших датасетах, гарантирует отсутствие дублей и пропусков.

Минусы: невозможно прыгнуть на 100-ю страницу, сложнее реализовать, требует сохранения состояния на клиенте.

Фильтрация

Параметры запроса:

GET /orders?status=pending&userId=user456
GET /orders?createdAfter=2025-01-01&createdBefore=2025-12-31
GET /orders?minAmount=50&maxAmount=500

Соглашения по имени полей:

• fieldname или filter_fieldname;
• minValue, maxValue для диапазонов;
• createdAfter, createdBefore для дат;
• q для полнотекстового поиска.

Защита от чрезмерно сложных запросов:

• максимальное количество условий (не более 10);
• ограничение по сложности условий;
• ограничение по длине параметров.

Сортировка

Параметры запроса:

GET /orders?sort=createdAt&order=desc
GET /orders?sort=amount&order=asc
GET /orders?sort=-createdAt  // минус означает desc

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

• сортировка только по индексированным полям;
• заранее определите, какие поля сортируются.

private static final Set<String> SORTABLE_FIELDS = Set.of(
    "id", "createdAt", "amount", "status", "userId"
);

Rate limiting и защита API

Назначение rate limiting

• Защита от DoS: злоумышленник не может перегрузить сервис;
• Защита от багов: ошибка в клиенте не рушит систему;
• Справедливое распределение ресурсов: один клиент не монополизирует ресурсы.

Виды лимитов

По IP-адресу:

Limit: 100 req/minute per IP

Плюсы: просто реализовать. Минусы: не работает за NAT или при балансировщиках.

По API-ключу/токену:

Authorization: Bearer api_key_12345
Limit: 10000 req/day per API key

Плюсы: гибко, привязано к клиенту. Минусы: требует аутентификации.

По пользователю/организации:

Authorization: Bearer jwt_token_...
Limit: 1000 req/hour per user

Плюсы: справедливое распределение по платёжному плану. Минусы: требует аутентификации.

Ответы при превышении лимита

Статус-код:

429 Too Many Requests

Заголовки с информацией:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1732694400
Retry-After: 60

Поля:

• X-RateLimit-Limit — максимум запросов;
• X-RateLimit-Remaining — остаток;
• X-RateLimit-Reset — Unix timestamp сброса;
• Retry-After — сколько секунд ждать.

Input validation

Ограничение длины строк:

@Size(min = 1, max = 100)
private String name;

@Email @Size(max = 255)
private String email;

Ограничения по числам:

@Min(1) @Max(1000)
int limit

Белые/чёрные списки:

if (sort != null && !SORTABLE_FIELDS.contains(sort)) {
    throw new BadRequestException("Invalid sort field");
}

На уровне API:

POST /orders
{ "items": [ ... ], "notes": "максимум 5000 символов" }

if (request.getItems().size() > 100) {
    throw new BadRequestException("Max 100 items");
}

Документация и контрактная разработка

Contract-first vs code-first

Contract-first:

1. Дизайнируется контракт (OpenAPI, Proto);
2. на его основе генерируются scaffold и SDK;
3. реализуется логика;
4. клиенты используют сгенерированные клиенты.

Плюсы: все договариваются до кодирования, меньше интеграционных проблем.

Code-first:

1. Пишется код;
2. из кода генерируется документация;
3. клиенты интегрируются.

Плюсы: быстрее на малых проектах. Минусы: расхождение между доком и кодом.

Использование контрактов для генерации кода

OpenAPI Generator:

openapi-generator-cli generate -i openapi.yaml -g java -o ./generated-client
openapi-generator-cli generate -i openapi.yaml -g spring -o ./generated-server

gRPC:

protoc --java_out=. --grpc-java_out=. orders.proto

BFF (Backend for Frontend)

Концепция

Backend for Frontend (BFF) — это слой API, оптимизированный для конкретного типа клиента.

Mobile App ──────┐
Web App ─────────┤──→ BFF for Mobile
Desktop App ─────┘
                     ├──→ BFF for Web
                     │
                     └──→ Internal Microservices

Каждый клиент общается со своим BFF, который:

• адаптирует контракты;
• компонует данные из микросервисов;
• кэширует;
• применяет rate limiting.

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

• Адаптация под UI: веб требует полных данных, мобильное — минимум;
• Снижение N+1 problem: BFF делает запросы и компонует результат;
• Кэширование: BFF кэширует ответы микросервисов;
• Изоляция: изменения микросервиса не видны клиентам.

Разделение ответственности

Внутренние сервисные API:

• минимальные, чёткие операции;
• часто используется gRPC;
• мелкозернистые ресурсы.

Внешние клиентские API (через BFF):

• композитные объекты;
• оптимизированы для UI;
• адаптированы под нужды клиента.

Консистентность данных и границы транзакций

Почему нельзя делать "толстые" API

API должны отражать границы транзакций. "Толстые" API размывают границы.

Пример плохого дизайна:

POST /orders/process
{ "userId": "user456", "items": [...], "paymentMethod": "card", ... }

// Сервер делает:
// 1. Валидирует пользователя
// 2. Резервирует товар
// 3. Обрабатывает платёж
// 4. Создаёт заказ
// 5. Отправляет уведомление
// всё в одном запросе

Проблемы:

• откат неатомарный;
• неясно, где произошла ошибка;
• невозможно переиспользовать операции;
• сложно тестировать.

Правильный баланс

Слишком чатти:

1. POST /cart → cartId
2. POST /cart/{id}/items → добавить товар
3. POST /orders → создать заказ
4. POST /payments → платёж

Много запросов, большой latency.

Слишком толстый:

POST /checkout
{ userId, products, coupon, paymentMethod, ... }

Один запрос, но неясно, что происходит.

Правильный баланс:

1. POST /orders { userId, items } → orderId
2. POST /payments { orderId, paymentInfo } → paymentId
3. GET /orders/{id} → актуальный статус

Каждый API:

• соответствует одной бизнес-операции;
• имеет чёткий контракт;
• может быть тестирован независимо;
• может быть переиспользован в разных контекстах.

Ключевые принципы проектирования API

Основные аспекты, которые нужно обсудить

1. Стиль: REST для публичного API, gRPC для микросервисов, события для асинхронности.

2. Модель данных: ясные ресурсы, контракты, DTO.

3. Идемпотентность: PUT идемпотентны, POST используют Idempotency-Key.

4. Обработка ошибок: консистентный формат с кодом, сообщением, деталями, traceId.

5. Версионирование: path versioning для публичного API (/v1, /v2), expand-only для внутреннего.

6. Пагинация: cursor-based для масштабируемости, limit/offset для простоты.

7. Rate limiting: по API-ключу, 429 при превышении.

8. Документация: OpenAPI/Protobuf, contract-first подход.

9. BFF: адаптированные слои для разных клиентов.

10. Консистентность: чёткие границы транзакций, ни слишком толстые, ни слишком чатти API.

Антипаттерны, которых нужно избегать

• Фокус только на URL без контракта;
• отсутствие идемпотентности;
• неправильная обработка ошибок;
• игнорирование версионирования;
• слишком чатти или слишком толстые API;
• отсутствие rate limiting;
• проброс внутренних деталей через API;
• жёсткое связывание через общую БД.

Заключение

Проектирование API — это архитектурное решение, которое влияет на масштабируемость, отказоустойчивость и удобство интеграции. Ключевые моменты:

• Контракт — более важен, чем конкретная реализация;
• Идемпотентность — обязательна в распределённых системах;
• Эволюция — API будут меняться, нужна стратегия;
• Слабая связанность — минимизируйте необходимые поля;
• Чёткие границы — каждый API — одна операция;
• Защита — rate limiting и валидация обязательны;
• Документация — единый источник правды.

Хранилища данных

Архитектурная роль хранилищ данных

Выбор хранилища является центральным архитектурным решением, определяющим производительность системы, масштабируемость, надёжность и стоимость эксплуатации. Хранилище взаимодействует со всеми компонентами архитектуры и оказывает прямое влияние на их проектирование.

Ключевые факторы при выборе хранилища

При архитектурном проектировании необходимо рассмотреть:

• Модель данных: насколько естественно выражаются сущности в выбранной системе (JOIN в реляционной модели, встроенные документы в document store'ах)
• Нагрузка на чтение/запись: профиль нагрузки влияет на применение индексов, денормализации, кешей и репликации
• Консистентность: выбор между strong consistency и eventual consistency определяет архитектурные компромиссы
• Доступность: требования к доступности указывают на необходимость репликации, отказоустойчивости и распределённых стратегий
• Масштаб данных: объём данных и количество пользователей влияют на выбор между вертикальным и горизонтальным масштабированием

Типы хранилищ и их характеристики

Реляционные базы данных (RDBMS)

RDBMS организуют данные в таблицы со строками и столбцами. Данные связаны через первичные и внешние ключи, запросы выполняются с помощью SQL. Системы гарантируют ACID-свойства и применяются в случаях, где требуется сильная консистентность и сложные связи между данными.

Применение RDBMS:

• Финансовые системы (бухгалтерия, платежи, транзакции)
• Системы управления (ERP/CRM, управление клиентами, заказами, складом)
• Системы с чёткой и стабильной структурой данных

ACID-гарантии:

• Atomicity (Атомарность): транзакция либо полностью выполняется, либо откатывается целиком
• Consistency (Согласованность): база данных переходит из одного согласованного состояния в другое с соблюдением всех ограничений целостности
• Isolation (Изоляция): одновременные транзакции не влияют друг на друга, каждая видит согласованный снимок данных
• Durability (Стойкость): после подтверждения транзакции данные сохраняются даже при сбое системы

Уровни изоляции транзакций

Уровни регулируют строгость видимости изменений между одновременными транзакциями:

• Read Uncommitted: транзакция видит незафиксированные изменения других транзакций (грязное чтение)
• Read Committed: видны только зафиксированные данные, но возможны неповторяемые чтения
• Repeatable Read: транзакция видит согласованный снимок данных, исключены неповторяемые чтения, но возможны фантомные строки
• Serializable: максимальная изоляция, транзакции выполняются так, как будто последовательно

Выбор уровня — это компромисс между корректностью и производительностью.

Модель данных в RDBMS: таблицы, ключи и связи

Реляционная модель использует:

• Первичный ключ: уникальный идентификатор строки, гарантирует уникальность
• Внешний ключ: ссылка на первичный ключ другой таблицы, обеспечивает целостность ссылок
• Составной ключ: комбинация нескольких столбцов в качестве уникального идентификатора

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

Нормализация

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

• Первая нормальная форма (1NF): каждый столбец содержит атомарное значение
• Вторая нормальная форма (2NF): все неключевые атрибуты зависят от всего первичного ключа
• Третья нормальная форма (3NF): неключевые атрибуты не зависят друг от друга через другие неключевые атрибуты

Плюсы нормализации:

• минимизация дублирования данных, экономия памяти
• гарантия целостности при изменениях
• ясная структура, удобство добавления новых сущностей

Минусы нормализации:

• необходимость JOIN'ов для получения полной информации об агрегате
• увеличение числа обращений к БД
• усложнение запросов

На высоконагруженных системах полная нормализация становится узким местом для чтения.

Индексы в RDBMS

Индекс ускоряет поиск на основе B-дерева, обеспечивая поиск за O(log n) вместо O(n).

Типы индексов:

• Индекс по одному столбцу: ускоряет поиск по этому столбцу
• Составной индекс: на нескольких столбцах, порядок имеет значение (ускоряет поиск по префиксу)
• Уникальный индекс: гарантирует уникальность значений

Баланс индексов:

Каждый индекс замедляет INSERT, UPDATE, DELETE операции, так как требует обновления индекса. На read-heavy системах индексы окупаются; на write-heavy требуется осторожный выбор.

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

Репликация (Primary–Replica):

• Master получает все write операции
• Replicas асинхронно применяют изменения из master
• Read операции распределяются между master и replicas

Плюсы: масштабирование чтения, отказоустойчивость

Минусы: eventual consistency (replicas отстают), read-after-write проблема, сложность failover'а

Шардирование (горизонтальное партиционирование):

Данные разделяются между несколькими БД по шард-ключу (например, по user_id). Каждый шард хранит подмножество данных.

Плюсы: масштабирование очень больших объёмов данных

Минусы: cross-shard запросы сложны, cross-shard транзакции почти невозможны, перебалансировка при добавлении шардов требует движения данных

Партиционирование внутри СУБД

Логическое разделение таблицы внутри одного сервера:

• Range partitioning: по диапазону значений (например, по дате)
• Hash partitioning: по хеш-функции от ключа
• List partitioning: по дискретному списку значений

Позволяет оптимизировать производительность и управление данными.

NoSQL базы данных

Мотивация для NoSQL

С ростом масштабов интернета традиционные RDBMS столкнулись с ограничениями:

• Горизонтальное масштабирование требует сложного шардирования
• Высокая нагрузка требует более простых моделей данных
• Распределённые системы требуют высокой доступности при разделениях сети
• Структура данных часто неизвестна заранее

BASE вместо ACID

Если ACID описывает свойства RDBMS, то BASE описывает распределённые NoSQL системы:

• Basic Availability: система остаётся доступной даже при сбоях компонентов
• Soft State: состояние может измениться из-за асинхронной репликации
• Eventual Consistency: данные в конечном итоге становятся согласованными

BASE не означает ненадёжность, а представляет другой компромисс: доступность и производительность вместо immediate consistency.

Key-value хранилища

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

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

• O(1) доступ, высокая производительность
• простое горизонтальное масштабирование
• отсутствие сложности JOIN'ов

Применение:

• Кеширование (Redis, Memcached)
• Хранение сессий
• Счётчики и рейтинги
• Конфигурационные данные
• Rate limiting

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

• Отсутствие возможности поиска без точного ключа
• Отсутствие связей и JOIN'ов
• Ограниченные или отсутствующие транзакции

Key-value хранилища используются как дополнительные, а не основные хранилища.

Document-ориентированные базы данных

Модель хранения: документы (JSON-подобные структуры) группируются в коллекции. Каждый документ может иметь свою структуру, поддерживается индексация и запросы по полям.

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

• Гибкая схема, нет enforcement структуры
• Естественное соответствие объектам приложения
• Встроенная поддержка вложенных структур и массивов

Применение:

• Профили пользователей
• Конфигурации и параметры
• Каталоги товаров
• Системы с вариативной структурой данных

Паттерны моделирования:

Embedding (вкладывание):

• Плюсы: одна операция получает всё, быстрое чтение
• Минусы: дублирование данных, увеличение размера документа

Reference (ссылка):

• Плюсы: отсутствие дублирования
• Минусы: требуется дополнительный запрос, возможны аномалии консистентности

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

Wide-column (колоночные) хранилища

Модель данных: таблицы с динамическими семействами столбцов. Данные организованы вокруг partitioning key и sort key, оптимизированы для быстрых записей и последовательного доступа.

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

• Write-optimized: данные сначала в памяти (memtable), затем на диск (sstable)
• Range queries: быстрый доступ к диапазону строк
• Time series: эффективное хранение метрик и логов

Применение:

• Time series data (метрики, котировки, IoT)
• Логирование и event streams
• Аналитика
• High-write нагрузки

Особенность: query-driven design — таблицы моделируются от запросов, не от сущностей.

Графовые базы данных

Модель данных: вершины (nodes) и рёбра (edges), где отношения являются первоклассным объектом системы.

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

• Естественное выражение связей
• Быстрые обходы графа

Применение:

• Социальные графы
• Рекомендательные системы
• Fraud detection
• Анализ зависимостей

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

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

CAP-теорема и её применение

CAP: фундаментальный компромисс

CAP-теорема гласит, что при сетевом разделении система вынуждена выбрать между двумя из трёх свойств:

• Consistency (Консистентность): все клиенты видят одинаковые данные
• Availability (Доступность): система остаётся функциональной
• Partition tolerance (Стойкость к разделению): система работает при разделении сети

Практические выборы:

• CP-системы: гарантируют консистентность, жертвуют доступностью при разделении сети
• AP-системы: гарантируют доступность, допускают временную несогласованность

PACELC: расширение CAP

PACELC дополняет CAP для нормальных условий работы:

• P (Partition): при разделении сети выбирайте между A и C
• E (Else): без разделения выбирайте между L (latency) и C (consistency)

Примеры:

• PA/EL (DynamoDB, Cassandra): при разделении приоритет доступности, в норме оптимизация задержки
• PC/EC (PostgreSQL synchronous): при разделении консистентность, в норме консистентность в приоритете
• PC/EL (Google Spanner): консистентность в обоих случаях, но оптимизация задержки

Консистентность в распределённых системах

Strong consistency vs eventual consistency

Strong consistency (immediate consistency):

После операции write все последующие операции read видят обновленные данные. Гарантия: в каждый момент существует одна правда.

Eventual consistency:

После write есть период, когда реплики содержат разные значения. Гарантия: при отсутствии новых write операций, рано или поздно все реплики синхронизируются.

Частные гарантии консистентности

Read-your-write (RYW) consistency:

После write операции, если тот же клиент прочитает данные, увидит своё обновление. Реализуется через sticky sessions или версионирование.

Monotonic reads (MR) consistency:

Клиент никогда не видит старые значения после прочтения более новых. Реализуется через версионирование.

Causal consistency:

Если операция B причинно зависит от операции A, все реплики видят A перед B. Требует логических часов или версионирования.

Выбор между хранилищами

Матрица решений

Критерии выбора по сценариям

Финансовые и платежные системы:

Выбор: RDBMS (PostgreSQL, Oracle) как основное хранилище + Redis для кеша

Причины: ACID необходима, структура чёткая, strong consistency критична, ошибки в eventual consistency приводят к потере денег

Логирование и аналитика:

Выбор: Wide-column (Cassandra, BigTable) или event log (Kafka)

Причины: экстремально высокий write volume, простая структура, eventual consistency приемлема

E-commerce: каталог и профили:

Выбор: Document store (MongoDB) для каталога + RDBMS для финансов

Причины: гибкая структура товаров, денормализованные профили; финансовые операции требуют ACID

Социальная сеть:

Выбор: RDBMS для основных сущностей + Redis для лент + специализированное хранилище для feed'ов

Причины: целостность, производительность лент, экстремальные читающие нагрузки

Нормализация и денормализация: архитектурный уровень

Нормализованный source of truth

Определение: source of truth — основное, авторитетное хранилище, где хранится истинное состояние системы.

Почему важно:

• Определяет, какие данные правильные при несогласованности
• Гарантирует целостность при восстановлении
• Упрощает архитектуру системы

Денормализованные проекции

Проекция (view, materialized view) — представление данных, оптимизированное под конкретный сценарий использования.

Примеры проекций:

• Кеш (Redis): быстрый доступ, TTL для инвалидации
• Search index (Elasticsearch): полнотекстовый поиск
• Materialized view: table, обновляемая по триггеру
• Документное хранилище: денормализованные агрегаты
• Data warehouse: факты для аналитики

Синхронизация:

• Push-based: события из source of truth → message broker → consumers обновляют проекции
• Pull-based: batch job'ы периодически обновляют проекции
• Streaming: CDC или логи репликации обновляют проекции в реальном времени

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

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

1. PostgreSQL: source of truth, нормализованные данные
2. Redis: кеш часто запрашиваемых данных
3. Elasticsearch: индекс для полнотекстового поиска
4. MongoDB: денормализованные проекции
5. Data warehouse: аналитические данные

События синхронизируют все хранилища через message broker (Kafka) или CDC.

Кеширование

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

Cache-aside (Lazy loading):

1. Приложение проверяет кеш
2. При miss читает из БД
3. Обновляет кеш для будущих запросов

Плюсы: гибко, приложение контролирует логику

Минусы: приложение отвечает за консистентность

Read-through:

Кеш автоматически загружает из БД при miss. Плюсы: просто, минусы: требуется конфигурация кеша.

Write-through:

При write приложение пишет и в кеш, и в БД синхронно. Плюсы: гарантия синхронизации, минусы: медленнее.

Write-behind (Write-back):

При write приложение пишет в кеш, кеш асинхронно пишет в БД. Плюсы: быстро, минусы: риск потери при crash'е кеша.

Инвалидация кеша

TTL (Time To Live): автоматическое удаление через время

Explicit invalidation: приложение явно удаляет при изменении данных

Event-driven invalidation: события из message broker инвалидируют кеш

Cache stampede

Проблема: популярный ключ истекает, сотни запросов одновременно идут в БД.

Решения:

• Probabilistic early expiration
• Locking на первый запрос при miss
• Lazy loading с async refresh'ем в фоне

Расчёт нагрузок и ёмкостей

Оценка требуемого объёма хранилища

Основная формула: Storage = (объём одного объекта) × (количество объектов)

Пример: система с 100 миллионами пользователей, профиль каждого ≈ 5 KB:

Storage = 5 KB × 100,000,000 = 500 GB

С репликацией (factor 3): 1.5 TB

Факторы:

• Индексы: обычно +30–50% от размера данных
• Логи репликации (WAL): +10–20%
• Запасный буфер: +20–50%

Оценка требуемой пропускной способности

IOPS (Input/Output Operations Per Second): количество операций в секунду

Пример: система с 1 миллионом пользователей, каждый пользователь генерирует 10 операций в день:

IOPS = (1,000,000 users × 10 ops/day) / (86,400 sec/day) ≈ 116 IOPS

С пиковой нагрузкой (10x): 1,160 IOPS

Оценка для read-heavy системы (80% read, 20% write):

Total IOPS = 1,160 / 0.2 = 5,800 IOPS (всего)
Read IOPS = 5,800 × 0.8 = 4,640
Write IOPS = 5,800 × 0.2 = 1,160

Оценка латентности

Типичные латентности при доступе:

• SSD случайный доступ: 1–10 мс
• SSD последовательный доступ: 0.1–1 мс
• RAM доступ: 0.001–0.01 мс
• Сетевой round-trip: 1–10 мс (LAN), 100+ мс (интернет)
• JOIN операция: добавляет latency пропорционально количеству таблиц

Пример: SELECT с 3 JOIN'ами может быть 10–50 мс на обычной конфигурации. С кешем в Redis (0.5–1 мс): значительное улучшение.

Выбор ёмкости хранилища

Оценка машины:

• PostgreSQL на одной машине: обычно 100–500 GB данных практично, большего требуется шардирование
• Redis (в памяти): 16–256 GB на машину, за пределами требуется clustering
• Elasticsearch: 50–100 GB на node (с 3-4 replicas это 200–400 GB total storage)

Правило большого пальца: планируйте на 10-кратный рост без архитектурных изменений.

Миграции схемы БД

Типы миграций

Additive: добавление столбцов, таблиц (обычно безопасно)

Destructive: удаление столбцов, таблиц (требует осторожности, может быть потеря данных)

Structural: изменение типов, переименование (требует тестирования)

Стратегии zero-downtime миграций

Blue-green deployment:

1. Запустить новую версию с новой схемой (green)
2. Перенести данные из blue в green
3. Перенаправить трафик на green
4. Снести blue

Canary deployment:

1. Мигрировать часть данных
2. Направить процент трафика на новую схему
3. Постепенно увеличивать процент
4. Полностью перейти на новую схему

Инструменты: Flyway, Liquibase (Java), управляют версионированием и применением миграций

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

Выбор между RDBMS продуктами

PostgreSQL предпочтителен для большинства систем благодаря мощи и надёжности.

Выбор между NoSQL документных хранилищ

Выбор между Key-value хранилищами

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

Выбор между Wide-column хранилищами

Cassandra для P2P распределённых систем, Bigtable/DynamoDB для облачных.

Резюме и принципы выбора

Систематический подход

1. Определить модель данных: сущности, связи, структура
2. Оценить нагрузку: read-heavy vs write-heavy, объём операций, объём данных
3. Определить требования к консистентности: strong vs eventual
4. Выбрать тип хранилища: на основе пунктов 1–3
5. Планировать масштабирование: как система вырастет?
6. Добавить слой кеша: для оптимизации
7. Спланировать миграции и восстановление: RTO, RPO

Отсутствие серебряной пули

Единого идеального хранилища не существует. Правильное решение:

• Совокупность хранилищ, каждое для своей роли
• Нормализованный source of truth
• Денормализованные проекции для оптимизации
• Кеш для скорости

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

Практические примеры и выбор архитектур

Типовые архитектуры для разных доменов

1. Социальная сеть / Messenger

Стек хранилищ:

Профили + Посты (основные данные)
    ├─ PostgreSQL (RDBMS)
    │  ├─ Таблица users (нормализованные профили)
    │  ├─ Таблица posts (базовые данные)
    │  └─ Таблица user_follows (граф дружб)
    │
    ├─ Redis (кеш)
    │  ├─ user:{id} → JSON профиля (TTL 1 час)
    │  ├─ post:{id}:likes → счётчик лайков
    │  └─ feed:{user_id} → кеш ленты (TTL 30 мин)
    │
    ├─ Elasticsearch (индекс)
    │  └─ Индекс всех постов для полнотекстового поиска
    │
    ├─ Cassandra (лента и временные ряды)
    │  ├─ user_feed (лента пользователя, отсортирована по timestamp)
    │  └─ post_engagement (лайки, комментарии, по времени)
    │
    ├─ Kafka (event log)
    │  ├─ user_created
    │  ├─ post_created
    │  ├─ post_liked
    │  └─ user_followed
    │
    └─ S3/GCS (медиа)
       └─ Фото, видео, прикрепления

Принцип работы чтения профиля:

1. App запрашивает профиль user_id
2. Проверить Redis user:{id}
3. Cache hit → вернуть JSON (1 ms)
4. Cache miss → запрос PostgreSQL (5 ms)
5. Кешировать в Redis (TTL 1 час)
6. Вернуть клиенту

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

1. App запрашивает ленту пользователя
2. Проверить Redis feed:{user_id}
3. Cache hit → вернуть список постов (1 ms)
4. Cache miss → запрос Cassandra (10–30 ms)
   SELECT * FROM user_feed WHERE user_id = ? 
   ORDER BY timestamp DESC LIMIT 20
5. Обогатить данные: получить профили авторов, счётчики лайков из Redis
6. Кешировать результат в Redis (TTL 30 мин)
7. Вернуть клиенту

Синхронизация при новом посте:

1. User создаёт пост
2. Запись в PostgreSQL
3. Отправить событие в Kafka (post_created)
4. Consumer'ы Kafka:

   - Индексируют в Elasticsearch
   - Добавляют в Cassandra user_feed подписчиков
   - Инвалидируют Redis кеш лент подписчиков
5. Счётчик лайков обновляется в Redis (volatile)
   Периодически sync в PostgreSQL (batch job)

2. E-commerce система

Стек хранилищ:

Каталог товаров
    ├─ MongoDB (document store)
    │  └─ Коллекция products (гибкая схема)
    │     {
    │       "_id": "prod_123",
    │       "name": "Товар",
    │       "price": 99.99,
    │       "attributes": {...}, // варьируется по типу товара
    │       "reviews": [...]
    │     }
    │
    ├─ Redis (кеш)
    │  ├─ product:{id} → JSON товара
    │  ├─ cart:{user_id} → содержимое корзины
    │  └─ inventory:{product_id} → текущий stock
    │
    └─ Elasticsearch
       └─ Индекс товаров для поиска и фильтрации

Заказы и платежи (финансовые)
    ├─ PostgreSQL (RDBMS, ACID)
    │  ├─ Таблица orders
    │  ├─ Таблица order_items
    │  ├─ Таблица payments
    │  └─ Таблица inventory (stock с lock'ами)
    │
    ├─ Redis (временный cache)
    │  └─ order:{id} → статус заказа (TTL 24 часа)
    │
    └─ Kafka (event log)
       ├─ order_created
       ├─ payment_processed
       └─ inventory_updated

Рекомендации
    ├─ Redis (горячие данные)
    │  └─ recommendations:{user_id} → список товаров
    │
    ├─ Cassandra (история покупок)
    │  └─ user_purchases (partition: user_id, cluster: timestamp)
    │
    └─ Batch job (нightly)
       └─ Analyse purchases → обновить recommendations в Redis

Процесс checkout'а:

1. User нажал «купить»
2. BEGIN TRANSACTION в PostgreSQL
3. SELECT inventory WHERE product_id = ? FOR UPDATE (блокировка)
4. Проверить stock >= quantity
5. UPDATE inventory SET quantity = quantity - quantity
6. INSERT INTO orders
7. INSERT INTO order_items
8. INSERT INTO payments (если платёж успешен)
9. COMMIT
10. Отправить событие order_created в Kafka
11. Инвалидировать Redis cart:{user_id}
12. Обновить recommendations (асинхронно)

Синхронизация инвентаря:

Inventory в Redis (кеш):
├─ product:123:stock → 150 (счётчик)
├─ DECR при добавлении в корзину (optimistic)
└─ Periodically reconcile с PostgreSQL

Если stock < 0 в Redis:
└─ Отклонить заказ при checkout'е (PostgreSQL имеет правду)

3. Финансовая система / Платежи

Стек хранилищ:

Основная БД (источник истины)
    └─ PostgreSQL (ACID, strong consistency)
       ├─ accounts (счета пользователей)
       ├─ transactions (все платежи)
       ├─ transaction_ledger (дебет/кредит для reconciliation)
       └─ user_balance_history (audit trail)

Replica для read-only (аналитика, отчёты)
    ├─ PostgreSQL Replica (async, отстаёт на несколько сек)
    │
    ├─ Redis (кеш)
    │  ├─ account:{id}:balance → текущий баланс (TTL 5 мин)
    │  └─ fraud_score:{user_id} → risk score (TTL 1 час)
    │
    └─ Elasticsearch (логирование)
       └─ Индекс для поиска по транзакциям

Архив (долгосрочное хранение)
    ├─ PostgreSQL архив (холодная таблица, partitioned по дате)
    │  └─ transactions_2023_* partitions
    │
    └─ Glacier / Archive (облачное хранилище)
       └─ Резервные копии старше 1 года

Гарантии при платеже:

Требования:
├─ RTO: 1 час (время восстановления)
├─ RPO: 15 минут (потеря данных max)
├─ ACID для каждого платежа
└─ No duplicate payments

Реализация:
├─ Синхронная репликация PostgreSQL на Standby
│  └─ Платёж записывается на Primary, затем на Standby
│  └─ Commit возвращается только после обоих
│
├─ Incremental backup каждые 15 минут
│  └─ WAL архивируется
│
├─ Idempotency key на клиенте
│  └─ transaction_id должна быть unique
│  └─ Повторный платёж с тем же ID возвращает ранний результат
│
└─ Audit log
   └─ Все платежи логируются для compliance

4. Логирование и мониторинг

Стек хранилищ:

Real-time инжест
    └─ Kafka (Message broker)
       ├─ Partition по server_id для порядка внутри сервера
       └─ Retention 24 часа

Time-series хранилище (горячие данные)
    ├─ Cassandra
    │  ├─ logs_by_server (partition: server_id+date, cluster: timestamp DESC)
    │  ├─ logs_by_level (partition: level+date, cluster: timestamp DESC)
    │  └─ Replication factor 3
    │  └─ Retention 30 дней
    │
    └─ InfluxDB (или Prometheus)
       └─ Метрики (CPU, memory, latency)

Full-text search
    └─ Elasticsearch
       ├─ Index logs (type: log)
       ├─ Rolling indexes logs-2024.01.15
       └─ Retention 7 дней (для performance)

Archive
    └─ S3 Glacier
       └─ Все логи > 30 дней (compressed)
       └─ Retention 1–7 лет (для compliance, audit)

Процесс инжеста:

1. Сервер отправляет лог в Kafka
2. Kafka buffer (smoothing peaks)
3. Consumer читает из Kafka
4. Пишет в Cassandra (async, buffered writes)
5. Пишет в Elasticsearch (async, bulk indexing)
6. Архивирует в S3 (batch job, ежедневно)

Запросы:

«Все ошибки сервера server_01 за последний час»
├─ Elasticsearch query (быстро: 10–50 ms)
│  GET logs/_search?q=server:server_01 level:ERROR timestamp:[now-1h TO now]

«Все логи пользователя за месяц»
├─ Cassandra query
│  SELECT * FROM logs_by_server 
│  WHERE server_id = 'server_01' AND date >= '2024-01-01'
│  ORDER BY timestamp DESC

«Какие сервера most frequently error'ят»
├─ Batch job на data warehouse
│  SELECT server_id, COUNT(*) as error_count
│  FROM logs_archive WHERE level = 'ERROR'
│  GROUP BY server_id
│  (Запускается раз в день)

Сравнение подходов для типовых проблем

Проблема: Очень быстро растущая система

Начало (день 1):

PostgreSQL single node
└─ Всё в одной БД

Неделя 1–2:

PostgreSQL + Redis
├─ Primary → Read replica
└─ Кеш горячих данных

Месяц 1–3:

PostgreSQL (primary-replica-replica)
├─ Redis (кеш)
├─ Elasticsearch (индекс для поиска)
└─ Kafka (event log для background jobs)

Месяц 3–6:

PostgreSQL (шардирование начинается)
├─ Shard 1: user_id 0–1M
├─ Shard 2: user_id 1M–2M
├─ Shard 3: user_id 2M–3M
└─ Остальной стек (кеш, индекс, логирование)

Месяц 6+:

Полиglot persistence
├─ PostgreSQL (основные данные, ACID)
├─ Cassandra (временные ряды, аналитика)
├─ Redis (кеш)
├─ Elasticsearch (поиск)
├─ Neo4j (социальный граф)
└─ S3 (медиа)

Проблема: Максимизация uptime

Минимальная архитектура (99.9% = ~44 минуты downtime/месяц):

Single PostgreSQL + Redis
├─ Backup каждый день
├─ Manual failover (1–2 часа)
└─ Acceptable для non-critical систем

Хорошая архитектура (99.99% = ~4 минуты downtime/месяц):

PostgreSQL Primary ↔ Standby (синхронная репликация)
├─ Automatic failover (1–2 минуты)
├─ Incremental backups каждый час
├─ Redis для кеша (потеря кеша — не критична)
└─ Suitable для большинства production систем

High-availability архитектура (99.999% = ~26 секунд downtime/месяц):

Data center 1:          Data center 2:
PostgreSQL Primary  ←→  PostgreSQL Standby
    ↓                       ↓
  Redis              (async replication)
    ↓
Load balancer (выбирает healthy datacenter)

├─ Synchronous replication к primary
├─ Async replication между DC'центрами
├─ Automatic geo-failover
├─ RPO: 0 (синхронно), RTO: 1–2 сек
└─ Suitable для финансовых / телеком систем

Проблема: Обработка экстремально высокой нагрузки

read-heavy (e.g., 100K read IOPS, 1K write IOPS):

Write → PostgreSQL Primary
Read → 
  ├─ Redis (90% hit rate) → 90K reads/sec
  ├─ Read replicas (9K reads/sec)
  └─ Fallback к primary (1K reads/sec)

Total throughput: 100K reads/sec достижимо

Write-heavy (e.g., 100K write IOPS):

Cassandra cluster (10 nodes)
├─ 10K write IOPS на node
└─ 100K total write IOPS

PostgreSQL не справит (max ~10K IOPS одной машины)

Mixed нагрузка с очень большим объёмом (petabytes):

Отделить по типам данных:
├─ Hot data (last 30 days) → PostgreSQL / Redis
├─ Warm data (1–12 месяцев) → Cassandra / HBase
└─ Cold data (архив) → S3 / Glacier

Routing logic на уровне приложения:
  if (age < 30 days) query PostgreSQL
  else if (age < 12 months) query Cassandra
  else query S3 archive

Типичные ошибки выбора

Ошибка 1: Выбор single технологии на все задачи

Неправильно:

Хранилище: MongoDB
├─ Финансовые операции (требуют ACID)
├─ Логирование (требуют high write throughput)
├─ Поиск (требуют полнотекстового индекса)
└─ Граф дружб (требуют traversal optimizations)

MongoDB может справить со всем, но неоптимально для каждого.

Правильно:

├─ PostgreSQL → финансовые операции
├─ Cassandra → логирование
├─ Elasticsearch → поиск
└─ Neo4j → социальный граф

Ошибка 2: Игнорирование консистентности требований

Неправильно:

Платежная система на DynamoDB (eventual consistency)
└─ Пользователь может дважды потратить деньги (race condition)

Правильно:

Платежная система на PostgreSQL (strong consistency)
└─ Платёж атомарен, нет race conditions

Ошибка 3: Забыт слой кеша

Неправильно:

Каждый запрос profile → PostgreSQL
└─ 100K RPS × 5 ms = высокая latency, нагрузка на БД

Правильно:

Запрос profile:
├─ Redis (TTL 1 час) → 1 ms, 90% hit rate
├─ PostgreSQL (10% miss) → 5 ms
└─ Средняя latency: 1.4 ms
└─ Нагрузка на БД: 10K RPS вместо 100K

Ошибка 4: Масштабирование запоздало

Неправильно:

День 1: PostgreSQL single node
День 30: 10M users, PostgreSQL на пределе
День 31: Срочно шардировать (24-часовой downtime)

Правильно:

День 1: PostgreSQL + Redis (заранее)
День 30: 10M users, система спокойно работает
День 60: Когда подойдёт time, добавить шардирование (zero downtime)

Контрольный список для Design Review

При выборе хранилищ для нового проекта:

Требования

• Определена модель данных (какие сущности, связи)
• Определён профиль нагрузки (read/write ratio, объём)
• Определены требования к консистентности
• Определены требования к доступности (SLA, uptime)
• Определены требования к масштабу (текущему и на год)

Выбор хранилища

• Выбран primary store (где живут основные данные)
• Обоснован выбор (почему именно эта БД)
• Рассмотрены альтернативы
• Определена ёмкость первого года
• Определена стратегия масштабирования

Слои оптимизации

• Есть ли кеш (Redis)?
• Есть ли индекс поиска (Elasticsearch)?
• Есть ли логирование (Kafka, Cassandra)?
• Есть ли source of truth + проекции?

Операционные требования

• Определены RTO и RPO
• Есть стратегия backup'а
• Есть стратегия failover'а
• Есть мониторинг (metrики, alerts)
• Есть процесс миграции схемы

Мониторинг и наблюдение

• Метрики БД (IOPS, latency, connections)
• Метрики приложения (запросы, ошибки)
• Alerts на аномалии (spike IOPS, latency)
• Процедура oncall для incidents

Кеширование

Роль кеширования в архитектуре систем

Кеширование — один из основных инструментов оптимизации производительности и масштабируемости. При проектировании нагруженных систем необходимо тщательно рассчитать эффект кеширования и его влияние на архитектуру.

Основной эффект кеширования: расчёты нагрузки

Снижение latency: Доступ к данным из памяти (микросекунды) на 1000-10000 раз быстрее, чем из БД (миллисекунды) или диска (десятки миллисекунд).

Разгрузка БД: При hit ratio = 80% нагрузка на БД падает в 5 раз. Это позволяет обслуживать в 5 раз больше пользователей на той же конфигурации.

Пример расчёта:

• Без кеша: 10 000 запросов/сек → 10 000 запросов в БД
• С кешем при hit ratio 80%: 10 000 запросов/сек → 2 000 запросов в БД (скоращение в 5 раз)
• Пропускная способность БД повышается за счёт кеша, позволяя служить в 5 раз больше пользователей

Снижение затрат на инфраструктуру: Дорогая БД требуется меньше; дешевая оперативная память справляется с пиками нагрузки; можно отложить масштабирование железа на 6-12 месяцев.

Улучшение качества обслуживания: Быстрый отклик приложения, плавная работа, лучший user experience.

Понимание компромиссов кеша

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

Ключевые метрики кеша

Hit ratio (коэффициент попаданий) = hits / (hits + misses) показывает долю запросов, успешно обработанных кешем:

• Менее 50% — кеш малоэффективен, требуется пересмотр стратегии
• 50-80% — хорошее кеширование
• Более 90% — отличное кеширование

Cache latency: Hit latency обычно < 1 мс. Рост до 10 мс указывает на проблемы (перегрузка, сетевые проблемы).

Memory efficiency: Соотношение размера кеша к количеству запросов, которые он экономит.

Eviction rate: Количество ключей, удаляемых в секунду из-за нехватки памяти. Высокий eviction rate указывает на недостаточный размер кеша.

Базовые понятия кеширования

Cache hit — запрос найден в кеше. Возврат данных быстр и эффективен.

Cache miss — запрос не найден в кеше. Система обращается к нижнему уровню (БД, API, диск). Это основной фактор, подлежащий оптимизации.

Warm cache (прогретый кеш) — кеш содержит популярные данные, hit ratio высокий, система работает эффективно. Достигается через pre-warming (предварительную загрузку) перед пиками.

Cold cache (холодный кеш) — только что запущенная система или очищенный кеш. Все первые запросы — miss'ы. Latency растёт, нагрузка на БД скачет вверх. Это явление требует специальной обработки через механизмы pre-warming и graceful fallback.

TTL (time to live) — время жизни записи в кеше. После истечения TTL запись считается невалидной. Пример: TTL=300 означает, что данные живут 5 минут, затем должны быть переполучены из источника.

Soft vs hard expiration:

• Hard expiration: когда TTL истёк, данные удаляются, cache miss гарантирован
• Soft expiration: данные помечены как устаревшие, но остаются доступны; в фоне происходит обновление

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

Стратегии вытеснения данных

LRU (Least Recently Used) — удаляются давно не использовавшиеся данные. Логика: неиспользованные данные менее вероятно потребуются вновь. Это стандарт для большинства кешей.

LFU (Least Frequently Used) — удаляются редко используемые данные. Логика: редкие данные менее ценны, чем частые.

FIFO (First In, First Out) — удаляются самые старые записи независимо от частоты использования. Проще в реализации, но менее эффективно.

Random — случайное удаление. Простое, но непредсказуемое.

На практике LRU используется чаще всего благодаря хорошему балансу между эффективностью и сложностью реализации.

Source of truth — основное хранилище истинных данных, обычно БД. Кеш всегда вторичен: это копия, потенциально устаревшая, которая может быть потеряна без последствий для целостности системы.

Уровни кеширования в архитектуре

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

1. Кеширование на стороне клиента

Браузерный кеш: Браузер кеширует HTTP-ответы согласно заголовкам Cache-Control, ETag, Last-Modified, Expires.

Плюсы:

• Нулевая нагрузка на сервер
• Максимальная скорость доступа
• Работает оффлайн

Минусы:

• Сложное управление инвалидацией
• Разные браузеры ведут себя по-разному
• Ограниченный контроль версионирования

Типичное использование: статические ресурсы (CSS, JS, изображения) с TTL от часов до дней.

Мобильные/desktop клиенты: Локальное хранилище (SQLite, файловая система).

Плюсы: работает оффлайн, не требует интернета для доступа к предыдущим данным

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

2. Кеширование на edge (граничных узлах)

CDN (Content Delivery Network): Статический контент (изображения, видео, файлы) хранится на серверах, географически близких к пользователям.

Плюсы:

• Глобальное распределение контента
• Низкая latency для пользователей по всему миру
• Масштабируемость

Минусы:

• Требуется правильная настройка TTL
• Инвалидация может быть медленной
• Отсутствие персонализированного кеша

Edge API caching: Некоторые edge-сервисы (Cloudflare, Akamai) кешируют GET-запросы к API.

Применимо для: публичных ответов, идентичных для всех пользователей (например, списки стран, курсы валют)

Не применимо для: персонализированных данных (профиль пользователя, его заказы, приватная информация)

3. Кеширование на уровне gateway/reverse proxy

Reverse proxy (Nginx, HAProxy) может кешировать ответы от backend'а с критериями:

• По пути: /api/products кешируется, /api/users/profile не кешируется (персональный)
• По заголовкам: если ответ содержит Cache-Control: no-cache, не кешируется
• По размеру: кешируются только ответы до определённого размера (например, до 1 МБ)

Микрокеши на несколько секунд: На уровне gateway устанавливается TTL = 5 секунд для популярных endpoint'ов. Это амортизирует пики нагрузки: если 1000 пользователей запросят один ресурс за 5 секунд, gateway пробивает в backend только один запрос.

Расчёт эффекта:

• RPS (requests per second) = 1000
• TTL = 5 сек
• Backend получит: 1000 / 5 = 200 RPS (вместо 1000)
• Нагрузка снижена в 5 раз

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

4. Кеширование внутри приложения (in-memory)

Локальные LRU-кеши в памяти процесса:

• Простейший вариант: ConcurrentHashMap с ручной реализацией LRU
• Продвинутый вариант: встроённые структуры (LinkedHashMap в Java)
• Высокий уровень: библиотеки с готовой логикой автоматического вытеснения

Плюсы:

• Максимальная скорость (памяти процесса, без сетевых задержек)
• Не требуется отдельный сервис
• Гибкость в управлении логикой

Минусы:

• Каждый инстанс приложения имеет свой независимый кеш
• При масштабировании на N инстансов, данные размножаются в N раз
• При перезагрузке инстанса кеш теряется
• Риск утечек памяти при неправильном управлении LRU

Типичное использование: кеширование конфигураций, справочников (справочники, которые редко меняются), результаты вычисления feature flags.

5. Распределённые кеши

Redis, Memcached: Отдельный сервис (или кластер), доступный всем инстансам приложения.

Технологии:

• Redis: более продвинутый, поддерживает различные структуры данных, персистентность, репликация
• Memcached: простой, очень быстрый, только key-value, in-memory only

Плюсы:

• Все инстансы видят один и тот же кеш, нет размножения данных
• Масштабируемость кеша независимо от приложения
• Встроенная поддержка кластеризации
• Redis поддерживает персистентность (RDB, AOF)

Минусы:

• Сетевая latency (хотя она остаётся низкой)
• Дополнительная инфраструктура для масштабирования и отказоустойчивости
• Риск: если кеш упадёт, весь трафик перенаправляется в БД (cache stampede)
• Требует управления репликацией и sharding'ом

Расчёт пропускной способности Redis:

• Redis single-threaded: примерно 50 000 - 100 000 ops/sec (в зависимости от размера данных)
• Для 100 000 RPS требуется кластер из минимум 10 Redis узлов
• При hit ratio 80%, 100 000 RPS → 20 000 запросов в Redis → один узел справляется

Комбинированный подход: многоуровневое кеширование

На практике Senior-система использует несколько уровней одновременно:

1. Браузерный кеш (HTTP-заголовки) для статики
2. CDN для глобально востребованного контента
3. Gateway кеш на несколько секунд для амортизации пиков
4. Локальный in-memory кеш в приложении для справочников и конфигов
5. Распределённый Redis для горячих данных (профили, заказы, сессии)

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

Пример многоуровневого кеша для микросервисной архитектуры e-commerce:

• Статика (CSS, JS, images): CDN, TTL=30 дней
• Список категорий: Gateway, TTL=1 час + локальный кеш, TTL=1 день
• Детали продукта: Gateway, TTL=5 минут + Redis, TTL=1 час
• Корзина пользователя: Redis только, TTL=24 часа
• Результаты поиска: Redis, TTL=5 минут (зависит от качества поиска и требований)

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

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

Cache-aside (lazy loading)

Алгоритм:

1. Приложение попытается прочитать данные из кеша
2. При hit — возвращаем данные
3. При miss — идём в БД, получаем данные, кладём в кеш, возвращаем приложению

if (cache.contains(key)) {
    return cache.get(key);
}
value = database.get(key);
cache.put(key, value);
return value;

Плюсы:

• Простота реализации, логика вся на стороне приложения
• Кеш — просто хранилище, не нужна специальная конфигурация
• Гибкость: кеш можно обойти при необходимости

Минусы:

• Cache miss всегда вызывает обращение в БД (тяжелая операция)
• Race-ситуация: если несколько потоков одновременно получат miss, все обратятся в БД
• Cold start: после перезагрузки кеша все первые запросы — miss'ы

Когда использовать: Основной паттерн. Применяется когда нужна простота, данные не критичны по свежести, допустимы occasional miss'ы.

Read-through

Алгоритм:

1. Приложение читает только из кеша
2. Кеш самостоятельно проверяет наличие данных
3. При miss кеш сам обращается в БД и загружает данные
4. Приложение получает результат, не зная о miss'е

Требования: Кеш должен быть "умным" — знать, как общаться с БД, какие логика запроса.

Плюсы:

• Чистота кода приложения, нет логики fallback'а
• Управление нагрузкой на БД происходит на уровне кеша

Минусы:

• Более сложная инфраструктура кеша
• Первый запрос на новый ключ всё равно медленный
• Кеш должен знать способ получения данных (проблематично при множественных источниках)

Когда использовать: В системах с managed service для кеша (облачные решения, специализированные кеши).

Write-through

Алгоритм при записи:

1. Записываем в кеш
2. Синхронно записываем в БД
3. Возвращаем успех только после обоих операций

cache.put(key, value);
database.put(key, value);
return success;

Гарантии: Кеш и БД всегда согласованы. При чтении из кеша данные всегда актуальны.

Плюсы:

• Гарантия консистентности
• Простая логика: write -> cache -> database
• Safe для критичных данных

Минусы:

• Запись медленнее: ждём ответа от обоих слоёв
• Если БД откажет, вся операция не пройдёт
• Не подходит для систем с высоким throughput на запись

Когда использовать: Когда консистентность критична, нагрузка на запись низкая или средняя (финансовые операции, заказы).

Write-behind / Write-back

Алгоритм:

1. Записываем в кеш
2. Немедленно возвращаем успех приложению
3. Асинхронно (в фоне) записываем в БД

cache.put(key, value);  // return immediately
asyncWrite(database, key, value);  // later

Плюсы:

• Запись очень быстрая: приложение получает ответ после кеша
• Высокий throughput на запись
• БД получает записи batch'ами, можно оптимизировать

Минусы:

• Риск потери данных: если кеш упадёт ДО асинхронной записи, данные теряются
• Асинхронная запись может завершиться с ошибкой, приложение об этом не узнает
• Возможна несогласованность: при чтении из БД до завершения асинхронной записи будут старые данные

Когда использовать: Для данных, где потеря или задержка некритична (аналитика, логи, метрики, счётчики). Для критичных данных (финансы, заказы) опасно использовать.

Refresh-ahead

Алгоритм:

• Отслеживаем, какие ключи часто читаются
• ДО истечения TTL проактивно обновляем эти ключи в фоне
• Когда TTL истекает, данные уже свежие

Плюсы:

• Нет cache miss на горячих ключах
• Гладкая работа без скачков latency
• Гарантия актуальности данных для popular keys

Минусы:

• Дополнительная логика для tracking и refresh
• Может быть неэффективно для cold ключей (зачем обновлять то, что никто не читает)
• Требует точную оценку популярности ключей

Когда использовать: Для критически важных горячих ключей, где miss полностью неприемлем.

Выбор данных для кеширования

Правильный выбор того, что кешировать, определяет эффективность всей системы.

Идеальные кандидаты на кеш

Справочники и редко меняющиеся данные:

• Списки стран, городов, валют
• Конфигурации и feature flags
• Справочники профессий, категорий

Причины: читаются часто, пишутся редко, потеря или устаревание данных на несколько часов некритично.

Результаты тяжёлых вычислений или агрегатов:

• Итоги за день/неделю/месяц
• Результаты сложных JOIN'ов нескольких таблиц
• Результаты ML-моделей

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

Популярные сущности (hot keys):

• 20% пользователей генерируют 80% запросов (закон Парето)
• Профили знаменитых людей в социальной сети
• Трендовые новости

Причины: кеш даст максимальный эффект на популярных данных, hit ratio будет высоким.

Сессии и временные данные:

• Данные сессии пользователя
• Temporary tokens
• Rate-limit счётчики

Причины: быстрый доступ критичен, персистентность не требуется, устаревание с TTL — нормально.

Данные, которые не стоит кешировать

Сильно изменяемые записи:

• Баланс счёта (обновляется каждую секунду)
• Статус заказа (часто меняется)
• Real-time счётчики

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

Расчёт: Если данные обновляются чаще, чем читаются повторно (ratio < 1:10), кеш неэффективен.

Чувствительные данные:

• Пароли, приватные ключи, токены (никогда не кешируем)
• PII (Personally Identifiable Information)

Причины: security-риск. Распределённый кеш может быть скомпрометирован. Локальный может быть выгружен на диск.

Данные, где критична последняя версия:

• Текущая позиция в реальном времени
• Статус платежа
• Решения по fraud-detection

Причины: ошибка на несколько секунд может быть дорогой или опасной.

Альтернативный source of truth:

• Избегаем неоднозначности: если кеш станет основным источником правды при сбое БД, система сломается

Принципы выбора для кеширования

"Читать чаще, чем писать": Если ключ читается в 10 раз чаще, чем пишется, кеш выгоден. Если ratio близок к 1:1, кеш бесполезен.

Формула ROI (return on investment) для кеша:

Выгода = (частота чтения - частота инвалидации) * (время из БД - время из кеша)
Стоимость = объём памяти * цена памяти + сложность управления инвалидацией

Разумная "грязность" данных: Senior-инженер понимает, что кеш не идеален. Данные могут быть на несколько секунд старше. Если это допустимо — кешируем.

Пример: профили пользователей с TTL=5 минут. Профили читаются в 1000 раз чаще, чем обновляются. За 5 минут может накопиться несколько изменений, но это приемлемо.

Проектирование ключей кеша

Ключ кеша — это адрес, по которому лежат данные. Плохой дизайн ключей приводит к конфликтам, дублированию и сложным ошибкам.

Структура ключа

Рекомендуемый формат:

<namespace>:<resource_type>:<resource_id>:<version>

Примеры:

• user:profile:12345:v1 — профиль пользователя 12345, версия 1
• product:details:67890:v2 — детали продукта 67890, версия 2
• session:token:abcdef:v1 — данные сессии
• cache:recommendations:user_12345:v1 — рекомендации для пользователя

Части ключа:

• namespace: категория данных (user, product, session, order). Избегаем коллизий
• resource_type: тип ресурса (profile, details, list, summary)
• resource_id: уникальный идентификатор (user ID, product ID, order number)
• version: версия формата (v1, v2). Нужна при изменении структуры данных

Требования к ключам

Уникальность: Разные данные — разные ключи. Коллизия приводит к возврату неправильных данных.

Предсказуемость: Приложение должно предсказать ключ для доступа. Не используем random или timestamp в ключе (если это не специальный случай).

Отсутствие конфликтов: Если сервис A использует user:123, а сервис B использует user:123 для своих данных — конфликт. Решение: prefix по сервису userservice:user:123 или auth_user:123.

Версионирование ключей

Проблема: Вы хранили User как {id, name, email}. Потом добавили phone. Старые записи в кеше не имеют phone. Новый код ожидает phone. Ошибка.

Решение: Меняем ключ на user:profile:123:v2. Старые записи user:profile:123:v1 останутся в кеше и будут проигнорированы (автоматически удалены по TTL). Новый код видит v2.

Процесс развёртывания:

1. Старый код читает v1, пишет v1
2. Выкатываем новый код. Он читает v2 (и fallback'и на v1 для старых данных)
3. За несколько дней/недель v1 исчезают по TTL
4. Код стабилизировался, удаляем поддержку v1

Преимущество: Zero-downtime развёртывание без необходимости очистки кеша.

TTL и стратегии инвалидации

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

TTL как основной механизм

Короткий TTL (10-60 секунд):

• Плюсы: данные чаще свежие, минимум рисков несогласованности
• Минусы: больше miss'ов, больше нагрузка на БД, hit ratio может упасть

Расчёт эффекта:

• Если RPS = 1000, TTL = 10 сек, hit ratio = 90%
• Miss RPS = 100. При miss требуется БД (10 ms). При hit < 1 ms
• Среднее время ответа = 0.9 * 1 ms + 0.1 * 10 ms = 1.9 ms

Длинный TTL (часы, дни):

• Плюсы: меньше miss'ов, высокий hit ratio, низкая нагрузка на БД
• Минусы: данные могут быть сильно устаревшими, риск user confusion

Trade-off: Выбираем TTL в зависимости от требований свежести:

• Для профилей пользователей: 5 минут (баланс между свежестью и производительностью)
• Для справочников: 1 час (редко меняются)
• Для статистики: 1 день (допустима старость)
• Для трендов: 1 минута (нужна относительная свежесть)

Инвалидация по событиям

Идея: Не ждём, пока TTL истечёт. Когда данные меняются в БД, выбиваем ключ из кеша.

Процесс:

1. Приложение обновляет запись в БД
2. Тут же вызывает cache.delete(key) или публикует событие
3. Следующий read получит fresh данные из БД

database.update(key, newValue);
cache.invalidate(key);

Плюсы:

• Гарантия свежести: как только данные обновились, кеш невалидирован
• Может использоваться с длинным TTL (кеш живёт долго, но инвалидируется по необходимости)

Минусы:

• Требует явной логики инвалидации в коде
• Риск "orphaned" данных: если забыть инвалидировать, данные в кеше будут стаканными
• При асинхронной инвалидации есть окно рассогласования

Event-driven инвалидация в микросервисной архитектуре

В распределённой системе часто используют события (message broker):

1. Сервис A обновляет User в БД
2. Публикует событие UserUpdated в Kafka/RabbitMQ
3. Сервис B слушает это событие и выбивает соответствующий ключ из Redis

Плюсы: Слабая связанность, асинхронность, масштабируемость

Минусы: Окно рассогласования (от ms до секунд), требуется инфраструктура для событий

Комбинированный подход

На практике используют:

• TTL = 5 минут (страховка, если забыли инвалидировать)
• Event-based инвалидация для критичных ключей (происходит в ms)
• При необходимости — явная инвалидация после операции (для consistency-critical сценариев)

Проблемы кеширования и их решения

Cache stampede (thundering herd)

Суть: Популярный ключ с TTL истекает. Одновременно к кешу приходит множество запросов. Все получают miss, все идят в БД. БД получает spike нагрузки.

Пример расчёта:

• RPS на ключ = 1000, hit ratio = 95%
• TTL = 60 сек
• В момент истечения: 950 одновременных miss'ов
• 950 запросов в БД одновременно (вместо обычных 50)
• БД загружена в 19 раз

Решение 1: Randomized TTL (джиттер)

ttl = 300 + random(0, 60);  // TTL от 300 до 360 секунд

Эффект: Ключи не истекают все сразу, spike размазывается.

Решение 2: Request coalescing / Locking

Когда первый запрос получил miss на ключ, он получает lock и идёт в БД. Остальные запросы ждут lock'а и получат результат от первого.

Решение 3: Soft TTL + background refresh

• Soft TTL = 290 сек: данные помечены как потенциально устаревшие, но ещё валидны
• Hard TTL = 300 сек: данные безусловно удаляются
• Когда данные попадают в soft period, запускается background refresh

Процесс:

1. Клиент читает ключ в soft period
2. Возвращаем ему старые данные (быстро)
3. В фоне обновляем ключ
4. Следующий запрос получит новые данные

Преимущество: нет miss'ов, всегда есть данные.

Cold start / холодный старт

Суть: Система только запущена, кеш пуст. Все первые запросы — miss'ы. Latency в пол, нагрузка на БД максимальна.

Проблема: Пока кеш не прогреется (5-10 минут), система работает нестабильно.

Решение: Pre-warming

При старте запускаем batch-job, который загружает популярные ключи:

1. Определяем top-100 ключей по частоте (из истории или конфига)
2. После старта сервиса запускаем pre-warming
3. Загружаем ключи из БД в кеш
4. Через 30 сек система готова к трафику

Пример расчёта:

• Top-100 ключей занимают 50% трафика
• Без pre-warming: первые 10 минут 90% hit ratio (вместо обычного 95%)
• С pre-warming: с первой минуты 95% hit ratio

Inconsistent cache (несогласованность кеша с БД)

Суть: Данные в кеше и БД не совпадают.

Пример:

1. Код читает из кеша: name=Иван
2. Одновременно другой процесс обновляет БД: name=Петр, но не инвалидирует кеш
3. Кеш возвращает: name=Иван
4. Несогласованность

Причины: забыли инвалидировать, асинхронность инвалидации, несогласованность между инстансами кеша в кластере.

Решение: Выбрать правильный паттерн (write-through для critical data, cache-aside с event-based инвалидацией для остального).

Кеш как single point of failure

Суть: Система полностью зависит от кеша. При падении кеша:

1. Все miss'ы идят в БД
2. Spike нагрузки на БД в 10+ раз
3. БД может перегрузиться
4. Cascading failure

Решение: Graceful degradation

• Circuit breaker: если кеш не отвечает, пропускаем кеш и идём в БД
• Fallback: если кеш упал, используем локальный кеш или timeout-friendly ответы
• Replicas: кеш имеет replicas для отказоустойчивости
• Load shedding: при spike нагрузки отклоняем низко-приоритетные запросы

Расчёт реплик:

• Expected load на кеш = 100 000 RPS
• Redis single узел = 50 000 ops/sec
• Требуется: 100 000 / 50 000 = 2 primary узла (минимум)
• Добавляем replicas: 2 primary + 2 replica = 4 узла total

Кеширование в микросервисной архитектуре

Локальный кеш vs распределённый кеш

Локальный in-memory кеш (в памяти процесса):

• Хранится в памяти процесса приложения
• Каждый инстанс имеет свой независимый кеш
• Примеры: ConcurrentHashMap, LinkedHashMap, Guava Cache, Caffeine

Плюсы: очень быстро (нет сети)

Минусы: размножение данных на N инстансов, потеря при перезагрузке

Распределённый кеш (Redis, Memcached):

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

Плюсы: консистентность, масштабируемость

Минусы: сетевая latency, зависимость от сервиса

Типичный паттерн в production-системе

1. Локальный кеш в каждом сервисе: справочники, конфиги, редко меняющиеся данные, TTL = час-день
2. Распределённый Redis: горячие данные, требующие синхронизации, TTL = минуты

При обновлении данных:

• Инвалидируем в Redis (быстро, доступно всем)
• Инвалидируем локальные кеши (через message broker)

Шардирование Redis для масштабирования

Расчёт шардирования:

• Требуемая пропускная способность: 100 000 RPS
• Redis single узел обрабатывает: 50 000 ops/sec
• Количество шардов: 100 000 / 50 000 = 2 шарда (минимум)
• С replicas (2x redundancy): 2 шарда * 2 replicas = 4 узла

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

• Consistent hashing: распределение ключей по кольцу
• Range-based: ключи по диапазонам (user IDs 0-1M, 1M-2M и т.д.)
• Directory-based: отдельный сервис маршрутизации

Мониторинг и операционные аспекты кеша

Ключевые метрики

Hit ratio = hits / (hits + misses):

• < 50% — неэффективно, требуется пересмотр
• 50-80% — хорошо

• 90% — отлично

Latency операций:

• Cache hit: < 1 ms (для in-memory), 1-5 ms (для Redis)
• Cache miss: 10-100 ms (зависит от БД)
• Средний latency = hit_ratio * hit_latency + (1 - hit_ratio) * miss_latency

Memory utilization:

• Текущий размер / лимит
• Trend: растёт или стабилен
• Eviction rate: ключей в sec, удаляемых по LRU

Availability:

• Uptime процентов
• Response time 95th/99th percentile

Capacity planning

Оценка размера кеша:

1. Определяем size одного объекта (среднее): User = 5 KB
2. Определяем count popular objects: 1M активных пользователей
3. Нужно: 1M * 5 KB = 5 GB
4. Добавляем резерв (1.5x): 5 GB * 1.5 = 7.5 GB
5. Выбираем Redis instance: 8 GB

Прогнозирование роста:

• Ежемесячно проверяем рост размера
• Если за месяц вырос на 20%, через 5 месяцев будет 100% (требуется масштабирование)

Технологии для кеширования

Основные решения и сравнение

Redis: основной выбор для распределённого кеша

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

• Single-threaded, но async I/O
• Встроенные структуры данных (Strings, Lists, Sets, Sorted Sets, Streams, HyperLogLog)
• Репликация master-slave
• Clustering для горизонтального масштабирования
• Персистентность (RDB snapshots, AOF write-ahead logs)
• TTL на ключи
• Transactions, Lua scripts

Варианты развёртывания:

• Standalone: простой, для development
• Sentinel: high availability, автоматический failover
• Cluster: горизонтальное масштабирование

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

Memcached: простое альтернативное решение

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

• Ультрапростой: только Key-Value для strings
• Многопоточный
• Очень быстрый
• Нет персистентности
• Нет репликации (требуется external solution)

Когда использовать: Когда нужна максимальная скорость и простота, не нужны сложные типы данных. Часто используется совместно с Redis.

Локальный кеш в Java: Caffeine

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

• High-performance in-memory cache
• Автоматическое вытеснение (LRU, LFU, W-TinyLFU)
• TTL и refresh по времени
• Built-in loader для lazy loading
• Асинхронная загрузка
• Полная функциональность в памяти процесса

Использование:

Cache<String, String> cache = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(5, TimeUnit.MINUTES)
    .recordStats()
    .build();

Когда использовать: Справочники, конфиги, редко меняющиеся данные внутри одного инстанца.

Выбор технологии: матрица решений

Принципы выбора подходов кеширования

Сравнительная таблица паттернов

Процесс выбора

Шаг 1: Определяем тип данных

• Read-heavy (10:1 reads:writes) → cache-aside или read-through
• Write-heavy (1:10 reads:writes) → write-through или write-behind
• Mixed (1:1) → может быть, не кешировать

Шаг 2: Определяем требования консистентности

• Strong consistency требуется → write-through
• Eventual consistency OK → cache-aside, write-behind
• No requirement → любой подход

Шаг 3: Определяем требования latency

• Low latency на write критична → write-behind
• Latency не критична → write-through, cache-aside
• Very low latency читаю (< 1ms) → local in-memory cache

Шаг 4: Выбираем

Примеры:

• Профили пользователей: Read-heavy (100:1), eventual consistency OK → cache-aside с Redis
• Финансовые транзакции: Write-through требуется, consistency critical → write-through с синхронизацией
• Логи и метрики: Write-heavy, loss OK → write-behind с batch писанием

Этот документ охватывает основные принципы, технологии, и подходы к кешированию в modern backend-архитектуре.

System Design: Очереди, брокеры сообщений и стриминг для асинхронного взаимодействия в микросервисной архитектуре с фокусом на надёжность, масштабирование и обработку отказов.

Роль очередей и стриминга в System Design

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

Зачем нужны очереди в распределённых системах

Синхронное взаимодействие через RPC или REST имеет критические недостатки. Если сервис A вызывает сервис B напрямую, то отказ B немедленно влияет на A. Кроме того, скорость A ограничена скоростью B, а всплески нагрузки мгновенно распространяются через систему. Очереди меняют эту динамику: продюсер (источник сообщений) и консьюмер (обработчик) больше не жёстко связаны по времени выполнения.

Брокер сообщений становится посредником. Продюсер публикует сообщение в очередь и продолжает работу, не дожидаясь обработки. Консьюмер берёт сообщение из очереди, когда готов, и обрабатывает его. Это асинхронное взаимодействие имеет три критических преимущества: слабая связанность (loosely coupled), буферизация пиков нагрузки и возможность масштабировать консьюмеров независимо от продюсеров.

Асинхронное взаимодействие как способ развязать компоненты

На собеседовании часто спрашивают: почему в твоей архитектуре используется очередь, а не прямой вызов? Ответ должен быть конкретным в контексте задачи. Очередь полезна, когда:

• Обработка сообщения может занять время, и продюсер не должен ждать
• Нужна защита от пиков нагрузки: всплески запросов буферизируются в очереди
• Консьюмеров нужно масштабировать или перезагружать без влияния на продюсеров
• Нужна дополнительная надёжность: сообщение сохранится на диск, даже если консьюмер упал

Интервьюер ждёт, что кандидат объяснит, почему для конкретной задачи очередь подходит лучше, чем других опций. Формулировка звучит так: «Мы используем очередь для обработки заказов, потому что операция платежа может занять секунды, а сам заказ нужно подтвердить немедленно. Очередь буферизирует пики, когда в час пик приходит 10x больше заказов, чем в среднем, и консьюмеры успешно обрабатывают их постепенно».

Event-driven архитектура как контекст

Когда интервьюер слышит фразу «event-driven архитектура», он ожидает, что кандидат продемонстрирует понимание того, что это означает на практике, а не просто назовёт buzzword. Event-driven подход подразумевает, что компоненты системы коммуницируют через события, происходящие в системе. Событие — это артефакт, представляющий факт того, что что-то произошло (OrderPlaced, PaymentReceived, UserRegistered).

На System Design-раунде это проявляется в способности кандидата объяснить цепочку: сервис генерирует событие → событие попадает в брокер → другие сервисы слушают это событие и реагируют. Это отличается от синхронного микросервисного взаимодействия, где OrderService явно вызывает PaymentService.

Базовые понятия

Сообщение (Message)

Сообщение — это атомарная единица информации, передаваемая между продюсером и консьюмером через брокер. Каждое сообщение состоит из двух частей: полезной нагрузки (payload) и метаданных (headers).

Полезная нагрузка содержит основную информацию. Метаданные включают ключи (keys), временные метки (timestamp), ID трассировки (trace-id, correlation-id), версию схемы и другие системные данные. Метаданные критичны для отслеживания и отладки цепочек обработки событий.

Формат сообщения выбирается в зависимости от требований:

• JSON: читаемый, простой в отладке, но многословный
• Avro: компактный, с вложенной схемой, поддержка эволюции схемы
• Protobuf: компактный, типизированный, используется в gRPC

На System Design кандидат не должен углубляться в детали каждого формата, но должен объяснить, почему он выбрал именно этот. Например: «Мы используем Avro, потому что консьюмеры пишут разные команды (Python, Go, Java), и Avro гарантирует совместимость схем при эволюции».

Очередь (Queue) и топик (Topic/Stream)

Это два разных способа организации хранилища сообщений, и различие между ними фундаментально для понимания выбора брокера.

Очередь — традиционная модель, реализованная в RabbitMQ, AWS SQS и подобных системах. Сообщение попадает в очередь, один из консьюмеров берёт его и обрабатывает. После успешной обработки (подтверждения, ack) сообщение удаляется из очереди. Это модель point-to-point: каждое сообщение обрабатывается ровно одним консьюмером в группе.

Топик/Стриминговый лог — модель, используемая в Kafka и подобных системах. Топик — это неизменяемый лог событий. Сообщения публикуются в топик и остаются там (обычно определённое время или размер). Каждый консьюмер может присоединиться к топику, прочитать все (или с определённой точки) события и отслеживать свою позицию через смещение (offset). Множество консьюмеров могут одновременно читать одно и то же событие.

Отличие принципиально: очередь удаляет сообщение после обработки, лог событий — сохраняет. Это означает, что в очереди потребитель может потеряться, если не успеет прочитать, а в логе можно переиграть события сначала.

Продюсер (Producer) и консьюмер (Consumer)

Продюсер — это компонент, который генерирует и публикует сообщения в брокер. На практике это может быть REST API, обработчик задачи, модуль обработки платежей — что угодно, что нужно уведомить о событии.

Консьюмер — это компонент, который читает сообщения из брокера и обрабатывает их. Это может быть микросервис, который реагирует на события, или фоновый worker, обрабатывающий задачи.

На собеседовании кандидат должен ясно описать, какие компоненты системы будут продюсерами, какие консьюмерами, и почему. Например: «OrderService публикует событие OrderPlaced, оно идёт в топик, на который слушают NotificationService (отправляет письма) и AnalyticsService (обновляет метрики)».

Consumer Group

Consumer group — это концепция для масштабирования обработки сообщений. Несколько экземпляров консьюмера объединяются в группу с одним именем. Брокер автоматически распределяет очереди (или партиции) между членами группы так, чтобы каждое сообщение обрабатывалось ровно одним консьюмером в группе.

Если в группе 5 консьюмеров и 10 партиций, каждый консьюмер обрабатывает 2 партиции. Если консьюмер падает, брокер перераспределяет его партиции между оставшимися. Это позволяет масштабировать горизонтально, просто запустив дополнительные экземпляры.

На System Design это звучит так: «Мы запускаем 10 экземпляров сервиса обработки заказов в consumer group, каждый обрабатывает сообщения из 5 партиций, что даёт нам параллелизм в 50 одновременных обработок».

Очереди vs Стриминговые логи

Классическая очередь (RabbitMQ-подобный подход)

В классической модели очереди сообщение проходит следующий цикл:

1. Продюсер публикует сообщение в очередь
2. Один из консьюмеров в группе берёт сообщение
3. Консьюмер обрабатывает сообщение
4. Консьюмер отправляет подтверждение (ack)
5. Брокер удаляет сообщение из очереди

Это модель competing consumers: несколько консьюмеров конкурируют за сообщения, и каждое сообщение обрабатывается ровно одним консьюмером. Очередь гарантирует, что сообщение не будет передано другому консьюмеру в той же группе.

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

• Простота: сообщение исчезает после обработки, не нужно управлять offsets
• Справедливое распределение нагрузки: быстрые консьюмеры обрабатывают больше, медленные меньше
• Память ограничена: старые сообщения удаляются

Недостатки:

• Невозможно переиграть события: если всё ломается, события теряются
• Нет истории: новый консьюмер не может узнать, какие события уже произошли
• Ограниченная гибкость: если нужно, чтобы несколько разных обработчиков слушали одно событие, нужны разные очереди или fan-out, что усложняет архитектуру

Стриминговый лог (Kafka-подобный подход)

В модели стриминга сообщения образуют append-only лог. Каждое сообщение получает порядковый номер (offset). Консьюмер отслеживает, какой offset он уже прочитал, и может продолжить с этой точки.

Модель выглядит так:

1. Продюсер публикует сообщение в топик, оно получает offset (например, 1000)
2. Консьюмер читает сообщение и сохраняет свой текущий offset (1000)
3. Если консьюмер падает и перезагружается, он знает, что уже прочитал до offset 1000, и начинает с 1001
4. Разные консьюмеры могут быть на разных offsets, каждый читает в своём темпе
5. Сообщение остаётся в логе (обычно определённое время или размер)

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

• Переигра событий: любой консьюмер может прочитать все события с начала
• Распределённость: множество независимых консьюмеров могут читать одни и те же события
• История: новый консьюмер может восстановить состояние, прочитав все события
• Гибкость в архитектуре: pub/sub без привязки к числу подписчиков

Недостатки:

• Управление offsets: консьюмер должен отслеживать свою позицию
• Требует хранения: лог логирует события, что требует дискового пространства
• Консьюмеры могут отставать на часы или дни, если не работают

Как выбирать между ними

Очередь подходит для задач, где каждое сообщение должно быть обработано ровно один раз, и история не важна. Пример: распределённая обработка задач (job queue), где задачи независимы, и новым воркерам не нужна история.

Стриминг подходит для систем, где требуется история событий, множество подписчиков, или возможность переигры. Пример: события в e-commerce, где разные сервисы (нотификация, аналитика, инвентарь) должны реагировать на один OrderPlaced, и могут потребоваться переигра событий при ошибке.

На собеседовании звучит так: «Для системы уведомлений нам подходит классическая очередь, потому что каждое письмо должно быть отправлено один раз, и историю писем нам не нужно. Но для синхронизации данных между сервисами мы используем Kafka, чтобы новые сервисы могли присоединиться и восстановить состояние, прочитав все события».

Модели доставки сообщений

At-most-once (доставка не более одного раза)

Семантика at-most-once означает, что сообщение либо доставлено ровно один раз, либо не доставлено вообще (потеряно). Не бывает дублей.

Как это реализуется:

• Продюсер публикует сообщение, он отправляется в брокер
• Если сеть разорвалась, продюсер не знает, дошло ли сообщение
• Консьюмер читает сообщение и ack'ает его перед обработкой
• Если консьюмер упадёт при обработке, сообщение уже ack'ено и потеряется

Где допустимо:

• Метрики и логирование: потеря одного события некритична
• Аналитика: погрешность в одно событие из миллиона не важна
• Некритичные уведомления: если письмо не отправилось, это не катастрофа

Где неприемлемо:

• Финансовые операции: потеря платежа недопустима
• Заказы: потеря OrderPlaced приведёт к потерям компании
• Критичные события: потеря любого события создаёт инкогерентность

At-least-once (доставка хотя бы один раз)

Семантика at-least-once означает, что сообщение гарантированно доставлено, но может быть доставлено несколько раз (дублирование возможно).

Как реализуется:

• Продюсер публикует сообщение, ждёт ack от брокера
• Консьюмер читает сообщение, обрабатывает его, и только потом ack'ает
• Если консьюмер упадёт при обработке, сообщение остаётся в брокере и будет переиграно

Это означает возможность дублирования:

• Продюсер отправляет сообщение, брокер получает, но ack теряется в сети
• Продюсер думает, что не дошло, отправляет снова
• Брокер получает два идентичных сообщения
• Оба доходят до консьюмера

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

На собеседовании звучит так: «Мы используем at-least-once доставку, потому что потеря сообщения недопустима, но мы спроектировали обработчик как идемпотентный: если приходит платёж дважды с одним и тем же ID, первый раз пополняется баланс, второй раз операция игнорируется благодаря upsert в БД».

Exactly-once (доставка ровно один раз)

Exactly-once — это философская концепция, которая обычно означает не буквальное гарантирование (это невозможно в распределённых системах), а "exactly-once семантика обработки" (exactly-once processing semantics).

Что это означает:

• На уровне приложения каждое сообщение обрабатывается ровно один раз
• Это достигается комбинацией механизмов: именованные идентификаторы сообщений, transactional offsets, распределённые транзакции

Как реализуется на практике:

• Консьюмер читает сообщение с ID 12345
• Обрабатывает его (например, пополняет баланс на 100)
• В одной транзакции записывает результат в БД и коммитит offset
• Если система упадёт, при рестарте консьюмер не переигра это сообщение, потому что offset уже закоммитен
• Если обработка не прошла, транзакция откатывается, и offset не обновляется

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

• Требует поддержки transactional writes в консьюмере и брокере
• Замедляет обработку (каждое сообщение — отдельная транзакция)
• Не решает проблему дублирования на стороне продюсера (если продюсер отправит дважды, два разных сообщения попадут в брокер)

На собеседовании кандидат должен объяснить, почему exactly-once часто не требуется: «Мы используем at-least-once с идемпотентными обработчиками, потому что exactly-once замедляет систему, а идемпотентность легко обеспечивается на уровне приложения через естественные бизнес-ключи».

Обсуждение delivery semantics на System Design

На раунде звучит так: «Для критичных операций нам нужна гарантия, что сообщение не потеряется. Мы используем at-least-once доставку, консьюмер читает сообщение, обрабатывает его, и только потом ack'ает. Но at-least-once означает возможность дублирования. Поэтому обработчик спроектирован как идемпотентный: платеж с одним ID обрабатывается ровно один раз благодаря уникальному ключу в БД».

Интервьюер оценивает, понимает ли кандидат разницу между моделями, и не смешивает ли их. Например, если кандидат говорит: «Мы используем Kafka и exactly-once», это хороший знак, что он читал документацию, но нужно убедиться, что он понимает цену и ограничения.

Надёжность, персистентность и репликация

Персистентные очереди

Персистентность означает, что сообщения записываются на диск, а не хранятся только в памяти. Это гарантирует, что сообщение не потеряется при падении ноды или отключении питания.

Как работает:

• Продюсер отправляет сообщение
• Брокер записывает сообщение на диск (или в WAL — write-ahead log)
• Брокер отправляет ack продюсеру
• Консьюмер позже читает сообщение с диска

Trade-offs:

• Надёжность vs Latency: запись на диск медленнее, чем в памяти. Обычно запись требует нескольких миллисекунд.
• Надёжность vs Пропускная способность: если каждое сообщение требует fsync (синхронизация на диск), пропускная способность падает. Для увеличения пропускной способности используется батчинг: несколько сообщений записываются вместе.

На собеседовании: «Мы используем персистентные очереди, потому что потеря заказов недопустима. Да, это добавляет несколько миллисекунд latency, но для асинхронного сценария это приемлемо. Брокер может обработать десятки тысяч сообщений в секунду благодаря батчингу и эффективной записи на диск».

Репликация в брокерах сообщений

Репликация означает, что каждое сообщение (или партиция) хранится на нескольких нодах. Если одна нода падает, данные остаются на других.

Как работает в Kafka (пример):

• Топик имеет 3 партиции, каждая реплицируется на 3 ноде (replication factor = 3)
• Партиция 0 имеет leader на ноде 1 и replicas на нодах 2, 3
• Продюсер пишет в leader
• Leader репликирует данные на replicas
• Консьюмеры читают из leader или replicas (в зависимости от конфигурации)
• Если нода 1 падает, брокер выбирает нового leader (нода 2 или 3)

Поведение при падении:

• Если только репли упала, система продолжает работать нормально
• Если leader упал, происходит избрание нового leader (занимает несколько секунд)
• Во время избрания leader новые сообщения не могут быть написаны, но чтение может продолжаться (в зависимости от конфигурации)

На собеседовании: «Каждая партиция реплицируется на 3 сервера. Если один сервер падает, данные остаются на двух других. Если падает leader, брокер автоматически выбирает нового leader из replicas, и система продолжает работать. Это гарантирует, что система выдержит падение одного сервера».

Acknowledgements (ack/nack)

Ack (acknowledgement) — это сигнал от консьюмера к брокеру, что сообщение успешно обработано и может быть удалено (или offset может быть обновлён).

Существуют две модели:

Автоматический ack (auto-commit):

• Консьюмер читает сообщение
• Через определённое время (конфигурируется) брокер автоматически ack'ает offset
• Если консьюмер упадёт, некоторые сообщения могут быть потеряны (те, которые были прочитаны, но не ack'ены)
• Плюс: простота
• Минус: возможна потеря

Ручной ack (manual commit):

• Консьюмер читает сообщение
• Обрабатывает его
• Явно отправляет ack брокеру
• Брокер обновляет offset
• Если консьюмер упадёт до обработки, сообщение будет переиграно

Влияние на семантику:

• Автоматический ack → at-most-once (может потеряться)
• Ручной ack (ack после обработки) → at-least-once (может дублироваться)
• Ручной ack (ack перед обработкой) → at-least-once и гарантия обработки (хотя обработка может быть незавершённой)

На практике используется ручной ack с обработкой перед ack'ем, что даёт at-least-once с минимальным риском потери.

Dead-letter queue (DLQ)

Dead-letter queue (DLQ) — это специальная очередь, в которую попадают сообщения, которые не удалось обработать. Это критический компонент надёжной системы обработки ошибок.

Назначение DLQ:

• Сообщение, которое не поддаётся обработке, не должно заблокировать очередь
• DLQ позволяет отделить "ядовитые" сообщения и обработать их отдельно
• Это позволяет оператору понять, что пошло не так, и принять решение

Как это работает:

1. Консьюмер читает сообщение
2. Обрабатывает его, но получает ошибку
3. Делает несколько попыток переобработки (с backoff)
4. Если все попытки исчерпаны, сообщение отправляется в DLQ
5. Отдельный процесс мониторит DLQ и алертирует операторов

Сценарии обработки DLQ:

• Ручной анализ: оператор смотрит сообщение, понимает, что пошло не так (например, неверный формат), исправляет и перекладывает обратно в основную очередь
• Автоматический реплей: после фиксации бага система автоматически переигрывает DLQ
• Отдельный сервис: специальный сервис анализирует DLQ, пытается восстановить некорректные данные, логирует проблемы

На собеседовании: «При обработке платежей мы используем DLQ. Если платёж не удалось обработать (например, нет такого аккаунта) после 3 попыток, он отправляется в DLQ. Отдельный alert ненаходить оператору, что в DLQ появилось сообщение, и оператор может расследовать причину».

Заказ (Ordering) и партиционирование

Гарантии порядка

Порядок сообщений важен для многих бизнес-сценариев. Например, если OrderPlaced должен прийти перед OrderConfirmed, нарушение порядка приведёт к несогласованности.

Когда брокер может обеспечить порядок:

• Сообщения в одной очереди / одной партиции обязательно обрабатываются в порядке, в котором они были опубликованы
• Но если очереди/партиции несколько, глобального порядка нет

Пример: топик с 1 партицией гарантирует порядок. Топик с 5 партициями гарантирует порядок только внутри каждой партиции.

Цена сохранения порядка:

• Если нужен глобальный порядок, нужна 1 партиция, это означает 1 консьюмер, параллелизм теряется
• На одном консьюмере пропускная способность ограничена до ~10k msg/sec (зависит от сложности обработки)
• Это часто неприемлемо для высоконагруженных систем

Партиции (Partitions)

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

Преимущества партиционирования:

• Параллелизм: N партиций → до N консьюмеров могут обрабатывать параллельно
• Масштабирование: добавление консьюмеров масштабирует throughput линейно (пока нет партиций больше, чем консьюмеров)
• Избежание хотспотов: разные партиции могут быть на разных нодах

Как связаны партиции и consumer group:

• Consumer group с 5 членами и топик с 10 партициями
• Брокер автоматически распределяет: консьюмер 1 обрабатывает партиции , консьюмер 2 обрабатывает , и т.д.
• Каждая партиция обрабатывается ровно одним консьюмером в группе

Ключ партиционирования (Partition Key)

Partition key — это значение, которое определяет, в какую партицию попадёт сообщение. Брокер хеширует ключ и выбирает партицию.

Как влияет на порядок:

• Если все сообщения для одного userId имеют одинаковый partition key (userId), они попадут в одну партицию и будут обработаны в порядке

Как влияет на распределение нагрузки:

• Хороший partition key распределяет нагрузку равномерно между партициями
• Плохой partition key приводит к дисбалансу

Примеры:

• userId для событий пользователя → гарантирует порядок для одного пользователя
• accountId для операций с счётом → гарантирует порядок для одного счёта
• orderId для событий заказа → гарантирует порядок для одного заказа

На собеседовании: «Событие содержит partition key = userId. Все события для одного пользователя попадут в одну партицию и будут обработаны в порядке. Для системы нужно 50 партиций для даже распределения нагрузки по 50 миллионам пользователей».

Trade-off: Порядок vs Масштабирование

Это критическое понимание на System Design:

• Если нужен глобальный порядок для всех сообщений, нужна 1 партиция, параллелизм невозможен
• Если нужен порядок внутри логической сущности (userId, accountId), используется partition key, это позволяет масштабировать до N партиций
• Если порядок не важен, можно игнорировать partition key, и нагрузка распределяется случайно

На собеседовании звучит так: «Для OrderPlaced и OrderCancelled нужен порядок (если OrderCancelled придёт до OrderPlaced, это ошибка). Мы используем partition key = orderId, это гарантирует, что все события для одного заказа обработаны в порядке. Мы имеем 100 партиций, что позволяет обрабатывать параллельно 100 различных заказов одновременно».

Идемпотентность и дедупликация

Зачем нужна идемпотентность при at-least-once доставке

At-least-once доставка означает, что сообщение может прийти дважды (или больше). Система должна быть спроектирована так, чтобы это не привело к некорректности.

Идемпотентность — это свойство операции, при котором выполнение её дважды даёт тот же результат, что и один раз. Например:

• Неидемпотентная операция: balance += 100 (выполнится дважды → баланс +200)
• Идемпотентная операция: balance = 100 (выполнится дважды → баланс = 100)

Подходы к идемпотентной обработке

Хранение processed-идентификаторов:

• Консьюмер хранит ID всех уже обработанных сообщений в таблице или кеше
• При получении нового сообщения проверяет, был ли он обработан
• Если да, пропускает обработку
• Минусы: нужна дополнительная таблица, нужно чистить старые ID'ы

Использование естественных ключей (business key):

• Сообщение содержит бизнес-ключ (например, paymentId = "pay_12345")
• В БД создаётся уникальный индекс на этом ключе
• Операция выполняется через INSERT OR UPDATE (upsert)
• Если такой paymentId уже есть, операция не изменит данные (или их обновит одинаково)
• Минусы: требует переделки схемы БД

Идемпотентные операции в БД:

• Вместо UPDATE balance SET balance = balance + 100 WHERE userId = 1, используется условное обновление
• Например: UPDATE balance SET balance = 100 WHERE userId = 1 AND balance < 100 (обновит только если баланс меньше 100)
• Это требует тщательного проектирования логики

Пример полной идемпотентной обработки платежа:

Консьюмер получает PaymentProcessed(paymentId='pay_123', userId=1, amount=100)
1. Проверяет: есть ли в БД Payment с paymentId='pay_123'?
2. Если есть, пропускает обработку (уже обработано)
3. Если нет, создаёт Payment(id='pay_123', userId=1, amount=100, status='processed')
   и обновляет balance: UPDATE users SET balance = balance + 100 WHERE id = 1
4. Отправляет ack брокеру
Если сообщение пришло дважды:

   - Второй раз Payment с paymentId='pay_123' уже есть, обработка пропускается
   - Баланс не увеличивается дважды

Дедупликация на стороне брокера и/или консьюмера

Дедупликация может быть реализована на разных уровнях:

На стороне консьюмера (рекомендуется):

• Консьюмер отвечает за идемпотентность
• Простая для реализации, не требует поддержки брокера
• Возможны оптимизации: если сообщение уже обработано, не нужно обращаться в БД

На стороне брокера:

• Брокер отслеживает ID сообщений и не позволяет отправить два идентичных
• Требует поддержки брокера (Kafka с версии 0.11 поддерживает idempotent producer)
• Не решает проблему дублирования на уровне приложения
• Усложняет логику брокера

Комбинированный подход:

• Брокер гарантирует, что он не пришлёт один message дважды продюсеру
• Консьюмер ещё обеспечивает идемпотентность приложения

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

Как на собеседовании связать семантику доставки и требования к обработчикам

Звучит так: «Мы используем Kafka с at-least-once доставкой. Это означает, что сообщение может прийти дважды. Чтобы система оставалась корректной, каждый обработчик спроектирован как идемпотентный. Для платежей мы сохраняем paymentId в БД с уникальным индексом, и вторая попытка обработки платежа с тем же paymentId просто пропустит операцию. Для аналитики мы используем свойства бизнес-ключа — если событие пришло дважды, аналитика обновляется на то же значение, что и в первый раз».

Паттерны использования сообщений

Point-to-point

Модель point-to-point используется, когда одно сообщение должно быть обработано ровно одним консьюмером.

Как работает:

• Один или несколько продюсеров публикуют сообщения в очередь
• Несколько консьюмеров образуют group и конкурируют за сообщения
• Каждое сообщение обрабатывается ровно одним консьюмером в группе

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

PaymentQueue → [ConsumerInstance1, ConsumerInstance2, ConsumerInstance3]
Каждый ConsumerInstance берёт задачу и обрабатывает её
Если задача требует 10 сек, а задач 1000, время обработки: 1000 * 10 / 3 ≈ 3333 сек ≈ 55 минут

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

Pub/Sub (публикация-подписка)

Модель pub/sub используется, когда одно событие должно быть доставлено множеству независимых подписчиков.

Как работает:

• Продюсер публикует событие в топик
• Множество разных потребителей (отдельные consumer groups) слушают топик
• Каждый группа получает своё копию события

Пример: событие OrderPlaced.

OrderService публикует OrderPlaced в топик
NotificationService (group=notification) читает события и отправляет письма
AnalyticsService (group=analytics) читает события и обновляет метрики
InventoryService (group=inventory) читает события и резервирует товар
Каждый сервис обрабатывает события независимо в своём темпе

Когда подходит: широковещательные события, разделение ответственности, слабая связанность сервисов.

Fan-out

Fan-out — это паттерн, при котором одно событие рассылается в несколько очередей или топиков.

Как работает:

• Событие попадает в exchange или topic
• Exchange имеет несколько bindings, каждая привязывает событие к отдельной очереди
• Событие копируется и отправляется во все очереди

Пример в RabbitMQ:

OrderPlaced → fanout exchange 'orders'
   → binding → queue 'notification'
   → binding → queue 'analytics'
   → binding → queue 'inventory'

Отличие от pub/sub:

• Pub/sub: один топик, множество independent consumer groups
• Fan-out: множество очередей, одна для каждого подписчика

На практике часто используется pub/sub, так как он более гибкий.

Request/Reply

Паттерн request/reply позволяет асинхронно отправить запрос и получить ответ через очередь.

Как работает:

1. RequesterService отправляет сообщение запроса в очередь requests с указанием replyTo='responseQueueForRequester'
2. ResponderService читает из requests, обрабатывает, отправляет ответ в responseQueueForRequester
3. RequesterService читает из responseQueueForRequester и получает ответ

Корреляция запрос-ответ:

• Каждый запрос имеет correlation-id (уникальный идентификатор)
• Ответ имеет тот же correlation-id
• Requester может сопоставить ответ с запросом

Пример:

RequesterService:
  Отправляет Message(correlationId='req_123', type='GetUserBalance', userId=1)
  Ждёт ответ с correlationId='req_123'

ResponderService:
  Получает Message(correlationId='req_123', type='GetUserBalance', userId=1)
  Обрабатывает: balance = 500
  Отправляет Message(correlationId='req_123', result=500)

RequestorService:
  Получает Message(correlationId='req_123', result=500)
  Знает, что это ответ на его запрос

Когда подходит: слабые связанные синхронные операции через очередь, когда нельзя использовать RPC (например, если ResponderService недоступен, запрос будет переиграться позже).

Event-carried state transfer

Паттерн event-carried state transfer подразумевает, что события несут полное состояние сущности.

Как работает:

1. OrderService генерирует OrderPlaced с полной информацией заказа (items, amount, customer, address, и т.д.)
2. Другие сервисы читают это событие и строят локальные проекции (кеши) данных заказа
3. Если потребуется информация о заказе, сервис берёт из локальной проекции, не обращаясь в OrderService

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

• Слабая связанность: другие сервисы не вызывают OrderService API
• Производительность: нет RPC при каждом запросе информации о заказе
• Отказоустойчивость: если OrderService недоступен, локальные проекции остаются

Недостатки:

• Данные могут быть устаревшими: если OrderService обновил заказ, другие сервисы узнают об этом с задержкой
• Размер события: событие должно содержать все данные, может быть большим
• Синхронизация: нужно обеспечить, чтобы все копии данных синхронизировались

На собеседовании: «Мы публикуем OrderPlaced с полной информацией заказа. NotificationService кеширует заказ локально, когда нужно отправить письмо, берёт данные из кеша вместо RPC в OrderService. Если заказ обновлён, OrderUpdated обновляет локальный кеш».

События в микросервисной архитектуре

Domain Events vs Integration Events

Domain Events (доменные события):

• События, которые происходят внутри микросервиса (bounded context)
• Описывают значимые изменения в доменной логике
• Примеры: UserRegistered, OrderConfirmed, PaymentProcessed
• Обычно обрабатываются внутри микросервиса для синхронизации состояния

Integration Events (интеграционные события):

• События, которые пересекают границы микросервисов
• Предназначены для уведомления других сервисов о значимых событиях
• Примеры: OrderPlaced (рассылается в брокер), PaymentCompleted (читается другими сервисами)
• Обычно проще по структуре, содержат только информацию для интеграции

Связь: доменные события обрабатываются внутри сервиса, и если нужно уведомить другие сервисы, издаётся интеграционное событие.

Пример:

OrderService получает команду PlaceOrder
  → внутренне генерирует доменное событие OrderPlaced
  → обновляет своё состояние на основе доменного события
  → издаёт интеграционное событие OrderPlaced в брокер сообщений
NotificationService слушает интеграционное событие OrderPlaced
  → обрабатывает его (отправляет письмо)

Event-driven архитектура

Event-driven архитектура — это подход, при котором компоненты системы коммуницируют через события, а не через синхронные RPC вызовы.

Принципы:

1. Слабая связанность: сервис A не вызывает сервис B напрямую, а публикует событие, на которое B реагирует
2. Асинхронность: обработка события может произойти с задержкой
3. Масштабируемость: легко добавить новый обработчик события, не меняя издателя

Архитектурная топология:

Синхронная архитектура:
OrderService → (sync call) → PaymentService
           → (sync call) → InventoryService
           → (sync call) → NotificationService

Event-driven архитектура:
OrderService → publishes OrderPlaced → message broker
                                        → PaymentService (consumer group 1)
                                        → InventoryService (consumer group 2)
                                        → NotificationService (consumer group 3)

На собеседовании: «Мы используем event-driven архитектуру для интеграции микросервисов. Когда OrderService создаёт заказ, он публикует OrderPlaced в Kafka. NotificationService, PaymentService и InventoryService подписаны на это событие и реагируют независимо. Это позволяет добавить новый сервис (например, AnalyticsService), не меняя OrderService».

Проекционная модель

Проекционная модель — это подход, при котором сервис ведёт локальные проекции (представления) данных, полученные из событийных потоков.

Как работает:

1. OrderService генерирует события об изменении заказов (OrderPlaced, OrderCancelled, OrderShipped)
2. ReportingService читает эти события и строит локальное хранилище отчётов
3. При запросе отчёта ReportingService берёт данные из локального хранилища, а не вызывает OrderService

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

• Оптимизированное хранилище: данные хранятся в той форме, которая оптимальна для запросов (например, денормализованные)
• Производительность: запросы не требуют RPC
• Гибкость: легко создать новую проекцию для других сценариев

Связь с CQRS:

• CQRS (Command Query Responsibility Segregation) разделяет команды (записи) и запросы (чтения)
• Проекционная модель часто используется с CQRS: проекции служат моделью чтения

Пример:

OrderService (Command Side):

  - Обрабатывает команды PlaceOrder, CancelOrder
  - Генерирует события OrderPlaced, OrderCancelled

OrderProjection (Query Side):

  - Читает события из Kafka
  - Обновляет таблицу orders в эластичном поиске
  - Когда приходит OrderPlaced, добавляет новый заказ в эластик
  - Когда приходит OrderCancelled, удаляет заказ из эластика

API Запрос GET /orders?status=shipped:

  - Читает из проекции в эластике (O(1) по сравнению с O(n) в основной БД)

Как на System Design рассказывать про события в микросервисах

Звучит так: «Когда заказ размещается, OrderService публикует доменное событие OrderPlaced. Это событие преобразуется в интеграционное событие и отправляется в Kafka. Несколько сервисов слушают это событие:

• NotificationService отправляет письмо клиенту
• InventoryService резервирует товар
• AnalyticsService обновляет метрики

Каждый сервис строит свою проекцию на основе событий. Например, OrderAnalytics обновляет таблицу в Elasticsearch с агрегированными данными о заказах. Это позволяет быстро отвечать на аналитические запросы без обращения к основной БД».

Очереди и устойчивость к пикам нагрузки

Очередь как буфер

Очередь служит буфером между продюсером и консьюмером, сглаживая всплески нагрузки.

Сценарий:

Без очереди:

  - API получает 10,000 requests/sec в час пик
  - Каждый request обрабатывает 5 сек
  - Нужно 50,000 экземпляров сервиса обработки
  - Стоимость: астрономическая
  - Даже с 50k экземпляров будут таймауты

С очередью:

  - API получает 10,000 requests/sec
  - API кладёт задачу в очередь (операция <1ms)
  - API отвечает клиенту: "OK, ваша задача в обработке"
  - 100 консьюмеров обрабатывают из очереди в своём темпе
  - Очередь накапливает задачи во время пиков
  - Время обработки всей нагрузки: 10,000 requests * 5 sec / 100 consumers = 500 сек ≈ 8 минут

Backpressure

Backpressure (противодействие давлению) — это механизм, при котором медленный консьюмер замедляет продюсера, чтобы предотвратить переполнение.

Как работает:

Сценарий 1: без backpressure (наивный)
API: Отправляю сообщение в очередь
API: Отправляю сообщение в очередь
API: Отправляю сообщение в очередь
... 10,000 сообщений за секунду
Очередь: заполняется, занимает 100 GB памяти
Очередь: выходит за лимиты хранилища
Система: падает

Сценарий 2: с backpressure
API: Отправляю сообщение в очередь (успешно)
API: Отправляю сообщение в очередь (успешно)
... 1000 сообщений
Очередь: достигнута максимальная глубина
API: Отправляю сообщение в очередь (зависает, ждёт место)
API: Таймаут, возвращаю клиенту ошибку 503 Service Unavailable
Клиент: повторяет запрос позже

Консьюмер: обработал сообщение и удалил из очереди
Очередь: появилось место
API: может отправить сообщение

Backpressure не просто решает проблему переполнения, она даёт клиенту сигнал, что система перегружена, и клиент может:

• Повторить запрос позже (с exponential backoff)
• Показать пользователю ошибку "система перегружена"
• Перенаправить трафик на другой сервер

Стратегии при переполнении очередей

Отбрасывание (dropping):

• Если очередь переполнена, новые сообщения отбрасываются
• Применимо только для некритичных данных (метрики, логи)
• Минус: теряются данные

Отложенная обработка (queuing with TTL):

• Сообщения остаются в очереди с TTL (time-to-live)
• Если сообщение не обработано за TTL, оно удаляется
• Применимо для задач, которые имеют смысл только в течение времени (например, "отправить напоминание")

Аварийные лимиты и алерты:

• Устанавливаются пороги: если глубина очереди > 50% вместимости, срабатывает alert
• Инженеры получают оповещение и могут добавить консьюмеров или оптимизировать обработку
• Если очередь заполнится полностью, наступает критический alert

Деградация функционала:

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

На собеседовании: «Когда в час пик приходит 10x нагрузка, API кладёт задачи в очередь. Очередь может накапливать до 1 млн задач. Если глубина очереди превышает 50%, срабатывает alert, и автоскейлер добавляет консьюмеров. Если глубина достигает 100%, новые запросы получают ошибку 503, и клиент повторяет позже».

Как проговаривать использование очередей для управления нагрузкой

Звучит так: «Вместо синхронной обработки, которая требует масштабировать воркеры в зависимости от пика нагрузки, мы используем асинхронную очередь. API немедленно кладёт задачу и отвечает клиенту. Фиксированное количество консьюмеров обрабатывает задачи в своём темпе. Это позволяет использовать на 80% меньше ресурсов для пиковой нагрузки, потому что нагрузка сглаживается. Очередь также служит буфером при временных сбоях: если БД недоступна на 5 минут, очередь будет расти, но задачи не потеряются».

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

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

Горизонтальное масштабирование означает добавление новых экземпляров консьюмера для обработки большего количества сообщений.

Как работает:

Начальное состояние:

  - Топик с 10 партициями
  - 2 консьюмера в группе
  - Каждый обрабатывает 5 партиций
  - Пропускная способность: 100 сообщений/сек (до тех пор, пока не будут обработаны)

Добавили 3-го консьюмера:

  - Брокер перераспределяет партиции
  - Консьюмер 1: партиции [0, 1, 2, 3]
  - Консьюмер 2: партиции [4, 5, 6]
  - Консьюмер 3: партиции [7, 8, 9]
  - Потенциальная пропускная способность увеличилась в 1.5 раза (зависит от бизнес-логики)

Добавили 5-го консьюмера:

  - Консьюмер 1: партиции [0, 1]
  - Консьюмер 2: партиции [2, 3]
  - Консьюмер 3: партиции [4, 5]
  - Консьюмер 4: партиции [6, 7]
  - Консьюмер 5: партиции [8, 9]
  - 6-й консьюмер будет бездействовать (нет партиций)
  - Максимальный параллелизм = число партиций = 10

Процесс перераспределения (rebalancing):

• Брокер уведомляет всех консьюмеров о необходимости перераспределения
• Все консьюмеры останавливают обработку и коммитят свои offsets
• Брокер пересчитывает распределение партиций
• Консьюмеры получают новое распределение и возобновляют обработку
• Время rebalancing: обычно 5-10 секунд

«Горячие ключи» (Hot Keys) и дисбаланс нагрузки

Hot key — это partition key, который генерирует непропорционально большой объём сообщений.

Пример:

Топик: UserEvents
Partition key: userId
Распределение:

  - userId 1-1000: 10 сообщений/сек каждый
  - userId 1001: 1,000,000 сообщений/сек (популярный пользователь)

Очки hash(userId) распределяются:

  - userId 1-1000 хешируются в разные партиции
  - userId 1001 хешируется в одну партицию

Результат:

  - Партиция с userId 1001 получает 99% всех сообщений
  - Партиция перегружена, консьюмер отстаёт
  - Другие партиции недогружены

Стратегии борьбы:

1. Композитные ключи:

Вместо:
  partition key = userId

Используй:
  partition key = userId + "_" + random(0, 100)

Результат:

  - userId 1001 теперь генерирует 100 разных partition keys
  - Сообщения распределяются в 100 разных партиций
  - Нагрузка распределяется равномерно
  
Минусы:

  - Теряется гарантия порядка для userId 1001
  - При запросе всех событий userId 1001 нужно читать из 100 партиций

2. Переразбиение (repartitioning):

• Увеличить число партиций (например, с 10 до 100)
• Даже hot key будет распределён хотя бы на несколько партиций
• Требует пересливания всех данных (обычно делается offline)

3. Отдельная топик для hot keys:

Основная UserEvents топик:

  - Обычные пользователи

HighVolumeUserEvents топик:

  - Только для пользователей с объёмом > 100k msg/sec
  - Имеет больше партиций

Консьюмер читает из обеих топик и объединяет

4. Локальный батчинг на продюсере:

Вместо:
  loop:
    send_event(userId=1001, ...)

Используй:
  batch = []
  loop:
    batch.append(event(userId=1001, ...))
    if len(batch) >= 100:
      send_batch(batch)
      batch = []

Результат:

  - Отправляется 100 событий в одном сообщении
  - Нагрузка на брокер снижается в 100 раз
  - Latency увеличивается немного (из-за батчинга)

Ограничение Concurrency (параллелизма)

Увеличение числа консьюмеров увеличивает параллелизм, но это может перегрузить downstream-систему (БД, API, и т.д.).

Пример:

Сценарий: OrderProcessing сервис читает заказы из очереди и записывает в БД

Вариант 1: 100 консьюмеров, каждый обрабатывает 1 сообщение за раз
  - Потенциальный параллелизм: 100 одновременных записей в БД
  - БД: 10 потоков для записи
  - Очередь перед БД: 90 задач ждут
  - Результат: БД перегружена

Вариант 2: 10 консьюмеров, каждый обрабатывает 1 сообщение
  - Потенциальный параллелизм: 10 одновременных записей
  - БД: может обработать 10 потоков
  - Результат: система сбалансирована

Как ограничить параллелизм:

1. Уменьшить число консьюмеров:

• Вместо 100 экземпляров, запустить 10
• Минус: потеря масштабируемости, если бизнес-логика быстрая

2. Ограничить batch size (размер батча):

Consumer config:
  max.poll.records = 10 (вместо дефолтного 500)
  
Результат:

  - Консьюмер берёт максимум 10 сообщений за раз
  - Обрабатывает их последовательно
  - Отправляет ack
  - Берёт следующий батч

3. Семафор/限流 внутри обработчика:

Semaphore s = new Semaphore(50); // макс 50 одновременных обработок

while (true) {
  message = consumer.poll();
  s.acquire(); // ждёт, пока не будет место в семафоре
  
  executor.submit(() -> {
    process(message);
    s.release();
  });
}

На собеседовании: «Для OrderProcessing мы использовали бы 20 консьюмеров с batch_size = 10 и семафором максимум 50 одновременных задач. Это гарантирует, что БД не будет перегружена более чем 50 одновременными записями, при этом мы сохраняем масштабируемость для пиков нагрузки».

Очереди и транзакционность

Проблема «двух систем»: БД + Брокер

Одна из ключевых проблем в распределённых системах: как обеспечить, что событие публикуется только если транзакция в БД успешна?

Сценарий проблемы:

Наивный подход:
  1. BEGIN TRANSACTION
  2. UPDATE orders SET status = 'confirmed' WHERE id = 123
  3. COMMIT
  4. broker.publish(OrderConfirmed)

Проблема 1: Откат транзакции
  1. BEGIN TRANSACTION
  2. UPDATE orders SET status = 'confirmed' WHERE id = 123
  3. COMMIT успешен
  4. broker.publish(OrderConfirmed) → брокер недоступен
  5. Заказ в БД подтверждён, но событие не публикуется
  6. Другие сервисы не знают, что заказ подтверждён

Проблема 2: Отправка перед коммитом
  1. BEGIN TRANSACTION
  2. UPDATE orders SET status = 'confirmed' WHERE id = 123
  3. broker.publish(OrderConfirmed)
  4. COMMIT → откатывается (например, нарушение уникальности)
  5. Заказ не подтверждён в БД, но событие уже опубликовано
  6. Другие сервисы ломаются, пытаясь обработать подтвержденный заказ

Outbox Pattern

Outbox pattern решает эту проблему, используя единственный источник истины — саму БД.

Как работает:

1. BEGIN TRANSACTION
2. UPDATE orders SET status = 'confirmed' WHERE id = 123
3. INSERT INTO outbox (event_type, payload, created_at) 
   VALUES ('OrderConfirmed', '{...}', NOW())
4. COMMIT (транзакция покрывает и заказ, и outbox)

Отдельный процесс (Polling Publisher):
5. SELECT * FROM outbox WHERE published_at IS NULL ORDER BY created_at
6. Публикует каждое событие в брокер
7. UPDATE outbox SET published_at = NOW() WHERE id = ...

Гарантии:

• Если транзакция откатывается, ни заказ, ни событие не создаются
• Если брокер недоступен, событие остаётся в outbox и будет переиграно позже
• Events публикуются в порядке, в котором они были созданы

Таблица outbox:

id | event_type | payload | created_at | published_at
---|------------|---------|------------|-------------
1  | OrderPlaced | {...} | 2024-01-01 10:00:00 | 2024-01-01 10:00:01
2  | OrderConfirmed | {...} | 2024-01-01 10:00:05 | NULL
3  | PaymentProcessed | {...} | 2024-01-01 10:00:07 | NULL

Transactional Outbox + Polling Publisher

На архитектурном уровне это выглядит так:

OrderService:

  - Spring Data Repository для Order
  - Spring Data Repository для Outbox
  - При создании заказа: save(Order) + save(OutboxEvent) в одной транзакции

PollingPublisher (отдельный процесс или сервис):

  - Каждые 100ms опрашивает: SELECT * FROM outbox WHERE published_at IS NULL
  - Для каждого события публикует в Kafka
  - UPDATE outbox SET published_at = NOW()
  - Идемпотентность достигается: если Kafka получил событие, но падение перед UPDATE,
    событие будет переиграно, но Kafka дедубликирует его

PollingPublisher может быть:

  - Отдельный сервис, читающий из БД OrderService
  - Встроенный в OrderService, запущенный в отдельном потоке

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

• Батчинг: опубликовать 100 событий за раз вместо по одному
• Дополнительная колонка для retry_count: перевести событие в DLQ если неудалось опубликовать 10 раз
• Партиционирование outbox таблицы по дате для лучшей производительности

Как на собеседовании объяснить решение проблемы «БД + брокер»

Звучит так: «Мы используем Outbox pattern. Когда OrderService создаёт заказ, в одной транзакции записывается заказ в таблицу orders и событие OrderPlaced в таблицу outbox. Отдельный PollingPublisher опрашивает outbox каждые 100 миллисекунд и публикует события в Kafka. Если публикация успешна, он помечает событие как опубликованное. Это гарантирует, что событие никогда не потеряется (даже если Kafka упадёт) и не дублируется (даже если PollingPublisher упадёт). Новый консьюмер может присоединиться и переиграть все события из Kafka».

Dead-letter Очереди и Обработка Ошибок

Классы Ошибок

Не все ошибки одинаковы. Важно различать:

Временные ошибки (transient errors):

• Сетевые таймауты: external API не ответил за 5 сек
• Временная недоступность: БД была недоступна 10 сек, теперь доступна
• Rate limiting: API ответил 429 (too many requests)
• Характеристика: при повторе позже, вероятно, пройдёт
• Стратегия: повторить с backoff

Постоянные ошибки (permanent errors):

• Валидация данных: сообщение содержит невалидный userId
• Логические ошибки: попытка перевести деньги со счёта без средств (может быть постоянная ошибка)
• Неверный формат: JSON не парсится
• Характеристика: повторы не помогут, нужна ручная интервенция
• Стратегия: отправить в DLQ и алертить операторов

Пример различия:

Сообщение: {"paymentId": "pay_123", "amount": -100}

Постоянная ошибка:

  - amount = -100 валидно? Нет, сумма не может быть отрицательной
  - Повторы не помогут, данные некорректны
  - DLQ + alert

Временная ошибка:

  - При первой попытке вызов БД: Connection timeout
  - При повторе: БД теперь доступна
  - Retry с backoff

Ретраи

Retry (повторная попытка) — это стратегия обработки временных ошибок.

Параметры ретраев:

max_retries: 3 (максимум 3 попытки)
initial_delay: 100ms (первый ретрай через 100ms)
backoff_multiplier: 2 (каждый ретрай дольше в 2 раза)
max_delay: 60s (но не больше 60 сек)

Таблица ретраев:
Попытка 1: immediate (ошибка)
Попытка 2: через 100ms (ошибка)
Попытка 3: через 200ms (ошибка)
Попытка 4: через 400ms (ошибка)
Итого 3 ретрая, все не удались → DLQ

Какие ошибки заслуживают ретраев:

if (exception instanceof SocketTimeoutException) {
  retry(); // временная сетевая ошибка
}
if (exception instanceof ConnectionException) {
  retry(); // БД недоступна
}
if (statusCode == 429) {
  retry(); // Rate limiting
}
if (statusCode == 5xx) {
  retry(); // Server error
}

if (statusCode == 400 || statusCode == 404) {
  skipToDeadLetter(); // Permanent error
}

На практике в Spring Boot:

@Retryable(
  value = { TemporaryException.class },
  maxAttempts = 3,
  backoff = @Backoff(delay = 100, multiplier = 2)
)
public void processMessage(Message msg) {
  // бизнес-логика
}

@Recover
public void recover(TemporaryException e, Message msg) {
  // отправить в DLQ
  deadLetterService.send(msg);
}

Перенос в DLQ

Критерии, когда сообщение считается "ядовитым" (poison message):

1. Все ретраи исчерпаны (max_retries превышено)
2. Ошибка постоянного характера (валидация, логическая ошибка)
3. Сообщение ломает инварианты (например, из-за некорректного формата)

Как попадает в DLQ:

Consumer:
  1. Читает сообщение из очереди
  2. Пытается обработать
  3. Ловит исключение
  4. Проверяет: это temporary или permanent?
  5. Если temporary и ретраи < max_retries: requeue (отправить обратно в очередь)
  6. Если permanent или ретраи исчерпаны: отправить в DLQ
  7. Отправить ack для исходного сообщения (чтобы оно не было переиграно)

DLQ консьюмер:

  - Читает из DLQ
  - Логирует сообщение и ошибку
  - Отправляет alert: "DLQ получило сообщение"
  - Сохраняет для анализа в отдельное хранилище

Сценарии обработки DLQ:

1. Ручной анализ:

Оператор:

  - Получает alert: "DLQ получило 5 сообщений"
  - Смотрит DLQ: все сообщения имеют невалидный userId
  - Понимает: бага в продюсере, он отправляет невалидные userId
  - Исправляет продюсер
  - Опционально: переигрывает сообщения из DLQ (если формат можно спасти)

2. Автоматический реплей:

После фиксации бага:
  1. Развернуть скрипт: SELECT * FROM dlq WHERE created_at > '2024-01-01 10:00'
  2. Для каждого сообщения: отправить обратно в основную очередь
  3. Консьюмер обработает сообщение повторно
  
Это работает, если баг был в обработчике, а не в самом сообщении

3. Отдельный сервис:

DLQAnalyzer сервис:

  - Читает из DLQ
  - Пытается восстановить сообщение (например, парсить из логов)
  - Классифицирует ошибку (временная vs постоянная)
  - Если можно спасти: отправить обратно
  - Если нельзя: отправить в архив и алертить

На собеседовании: «При обработке платежей, если консьюмер не может обработать сообщение после 3 ретраев, он отправляет его в DLQ. Отдельный DLQ консьюмер логирует сообщение и отправляет alert инженерам. Инженер может посмотреть, что пошло не так (например, невалидный formattorr в сообщении), исправить бага и переиграть сообщения из DLQ».

Лог Событий как Источник Истины

Событийный Лог (Event Log)

Событийный лог — это append-only структура данных, которая хранит полную историю всех событий, произошедших в системе.

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

• Append-only: сообщения только добавляются, не удаляются и не обновляются
• Упорядоченность: каждое сообщение получает монотонно возрастающий номер (offset)
• Переигра: можно прочитать все события с начала и воспроизвести любое прошлое состояние

Примеры событийных логов:

• Kafka топик: append-only логирование сообщений
• WAL (Write-Ahead Log) в БД: логирование всех изменений перед применением

Пример лога:

Offset | Timestamp | EventType | Payload
-------|-----------|-----------|----------
0      | 10:00:00  | UserCreated | {"id": 1, "name": "Alice", "email": "alice@example.com"}
1      | 10:00:05  | OrderPlaced | {"id": 1, "userId": 1, "amount": 100}
2      | 10:00:10  | PaymentProcessed | {"orderId": 1, "status": "success", "txnId": "tx_123"}
3      | 10:00:15  | OrderConfirmed | {"orderId": 1}
4      | 10:00:20  | OrderShipped | {"orderId": 1, "trackingId": "track_456"}

Event Sourcing (На Уровне Понятий)

Event sourcing — это архитектурный паттерн, при котором состояние сущности не хранится напрямую, а вычисляется путём воспроизведения всех событий, затрагивающих эту сущность.

Сравнение подходов:

Традиционный подход (state storage):

Таблица orders:
  id | status | amount | created_at
  1  | shipped | 100 | 2024-01-01 10:00
  
При запросе: SELECT status FROM orders WHERE id = 1 → "shipped"
При обновлении: UPDATE orders SET status = 'delivered'

Event sourcing подход:

Таблица order_events:
  orderId | eventType | payload | timestamp
  1 | OrderPlaced | {"amount": 100} | 2024-01-01 10:00:00
  1 | PaymentProcessed | {"status": "success"} | 2024-01-01 10:00:05
  1 | OrderConfirmed | {} | 2024-01-01 10:00:10
  1 | OrderShipped | {"trackingId": "track_456"} | 2024-01-01 10:00:15
  1 | OrderDelivered | {} | 2024-01-01 10:00:20

При запросе статуса:
  1. Читаем все события для orderId=1 в порядке
  2. Применяем их по очереди:

     - После OrderPlaced: status = "placed"
     - После PaymentProcessed: status = "confirmed"
     - После OrderShipped: status = "shipped"
     - После OrderDelivered: status = "delivered"
  3. Возвращаем: "delivered"

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

• Полная аудитория: все изменения зафиксированы
• Способность к переигре: можно восстановить любое прошлое состояние
• Аналитика: легко видеть, как часто переходит из статуса в статус

Недостатки:

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

Связь с CQRS и Проекциями

Event sourcing часто используется с CQRS (Command Query Responsibility Segregation):

• Command Side: события хранятся в event store
• Query Side: на основе события генерируются проекции (денормализованные представления)

Event Store:

  - OrderPlaced(id=1, amount=100)
  - PaymentProcessed(orderId=1, status=success)

Проекция в таблице Order (денормализованная):
  id | status | amount
  1 | confirmed | 100

Проекция в таблице UserBalance (отдельная):
  userId | totalSpent
  1 | 100

При запросе: берём из проекции (быстро), не воспроизводим события (медленно)
При написании события: обновляем проекции

Разница между Логом Интеграционных Событий и Event Store

Лог интеграционных событий (обычно Kafka):

• События публикуются между сервисами
• Используется для асинхронной интеграции
• Может быть ephemeral (события удаляются через время)
• Пример: OrderPlaced в Kafka, NotificationService слушает и отправляет письма

Event Store (обычно БД):

• События хранятся в единственном источнике истины
• Внутри сервиса для event sourcing
• Обычно постоянный (events не удаляются)
• Пример: все события для Order в PostgreSQL, используются для воспроизведения состояния

На практике часто используется комбинация:

OrderService:

  - Event Store (в БД): все события для заказов
  - Event Publisher: читает Event Store, публикует интеграционные события в Kafka
  
Другие сервисы:

  - Слушают интеграционные события в Kafka
  - Не имеют доступа к Event Store OrderService

Использование Очередей и Стриминга для Интеграций

Интеграция Между Внутренними Сервисами

Event-driven интеграция заменяет синхронные RPC вызовы асинхронными событиями.

До (синхронная интеграция):

OrderService.placeOrder(order):
  1. Создать заказ в БД
  2. Вызвать synchronously InventoryService.reserveItems(items)
     - Если InventoryService упал → весь placeOrder падает
     - Если InventoryService медленный → placeOrder ждёт
  3. Вызвать synchronously PaymentService.processPayment(amount)
     - Если PaymentService упал → весь placeOrder падает
  4. Вызвать synchronously NotificationService.sendEmail(...)
     - Если NotificationService упал → весь placeOrder падает
  5. Вернуть результат клиенту

После (асинхронная интеграция через события):

OrderService.placeOrder(order):
  1. Создать заказ в БД
  2. В outbox записать событие OrderPlaced
  3. Вернуть результат клиенту немедленно
  
PollingPublisher:

  - Публикует OrderPlaced в Kafka

InventoryService (слушает OrderPlaced):

  - Резервирует товар
  - Публикует ItemsReserved или ReservationFailed

PaymentService (слушает OrderPlaced):

  - Обрабатывает платёж
  - Публикует PaymentSucceeded или PaymentFailed

NotificationService (слушает OrderPlaced):

  - Отправляет письмо
  - Может отработать с задержкой

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

• Слабая связанность: OrderService не зависит от других сервисов
• Отказоустойчивость: если PaymentService упал, OrderService продолжает работать
• Масштабируемость: можно добавить новый сервис (например, AuditService) без изменения OrderService

Интеграция с Внешними Системами

Очереди используются как буфер при интеграции с нестабильными внешними API.

Сценарий:

OrderService должен отправить заказ в интеграцию с logistics API:

  - API может быть недоступна
  - API может быть медленной
  - API может рейт-лимитить запросы

Решение с очередью:
  1. OrderService создаёт заказ, публикует OrderPlaced
  2. LogisticsAdapter слушает OrderPlaced
  3. LogisticsAdapter берёт заказ из очереди (из своего темпа)
  4. LogisticsAdapter вызывает внешнее API
  5. Если API недоступна: сообщение остаётся в очереди, переиграется позже
  6. Если API рейт-лимитирует: LogisticsAdapter замедляется, очередь буферизирует нагрузку

Адаптер (логика):

LogisticsAdapter:

  - Читает из очереди с batch_size = 10 (не забомбить внешнее API)
  - Вызывает external_api.createShipment(order)
  - Если успешно: ack сообщение
  - Если failure с retry: положить обратно в очередь или переиграть позже
  - Если permanent failure: отправить в DLQ

Change Data Capture (CDC)

Change Data Capture (CDC) — это способ автоматически захватывать изменения в БД и публиковать их в качестве событий.

Как работает:

1. Основная БД (например, PostgreSQL):

   - Таблица orders: id | status | amount
   
2. CDC инструмент (например, Debezium):

   - Читает логи репликации БД (WAL, binlog, и т.д.)
   - Видит: UPDATE orders SET status = 'confirmed' WHERE id = 1
   - Генерирует событие: OrderUpdated(id=1, status='confirmed')
   - Публикует в Kafka топик 'db.orders.changes'
   
3. Другие системы читают из Kafka:

   - SearchService обновляет индекс в Elasticsearch
   - CacheService инвалидирует кеш
   - ReportingService обновляет отчёты

Примеры инструментов:

• Debezium: универсальный CDC для PostgreSQL, MySQL, MongoDB, и т.д.
• AWS DMS: Change Data Capture для AWS
• LinkedIn Databus: внутренний CDC LinkedIn

Когда подходит:

• Синхронизация между системами (одна система — source of truth, остальные зеркалят)
• Миграция данных (новая система читает изменения из старой)
• Aудит (все изменения логируются)

На собеседовании: «Для синхронизации OrderDB с SearchIndex, мы используем Debezium CDC. Все изменения в PostgreSQL автоматически захватываются и публикуются в Kafka. SearchService читает из Kafka и обновляет Elasticsearch. Это гарантирует консистентность между БД и индексом».

Observability и Эксплуатация Очередей и Стриминга

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

Нужно мониторить здоровье очередей и потребителей:

1. Длина очереди / Lag (отставание):

Lag = offset_of_new_messages - offset_of_consumer

Пример:

  - Продюсер опубликовал сообщения до offset 1000
  - Консьюмер обработал до offset 950
  - Lag = 1000 - 950 = 50

Метрика в Prometheus:
  kafka_consumer_lag{topic="orders", group="payment-service", partition="0"}

Интерпретация:

• Lag = 0: консьюмер в ногу с продюсером (отличное состояние)
• Lag = 100: консьюмер отстаёт на 100 сообщений (нормально, если не растёт)
• Lag = 100,000 и растёт: консьюмер не поспевает за продюсером (критическая ситуация)

2. Скорость обработки (messages/sec):

Метрика: сообщений, обработанных за секунду

Отличное: 1000 msg/sec
Нормальное: 500 msg/sec
Плохое: 10 msg/sec (консьюмер очень медленный)

3. Время жизни сообщения в очереди (age):

Age = now() - message_timestamp

Пример:

  - Сообщение создано в 10:00:00
  - Сейчас 10:05:00
  - Age = 5 минут
  
Отличное: age < 1 сек (обрабатывается быстро)
Нормальное: age < 1 мин
Плохое: age > 1 часа (сообщение застряло)

4. Ошибки и DLQ сообщения:

Метрика 1: количество сообщений в DLQ
  - DLQ пуста: хорошо
  - В DLQ 10 сообщений: расследовать
  - В DLQ растёт: критическая ошибка

Метрика 2: частота ошибок (errors/sec)
  - Ошибки 0/sec: идеально
  - Ошибки 1-5/sec: допустимо (в зависимости от общего объёма)
  - Ошибки 100+/sec: проблема

Логирование

Лог-ориентированное отслеживание критично для отладки распределённых систем.

Correlation ID / Trace ID:

Исходный запрос:

  - API получает запрос: POST /orders
  - Генерирует traceId = "trace_12345"
  - Записывает в лог: traceId=trace_12345 msg="Order placed"

Событие в Kafka:

  - Сообщение содержит: {"traceId": "trace_12345", ...}

DownstreamService:

  - Читает из Kafka
  - Извлекает traceId = "trace_12345"
  - Записывает в лог: traceId=trace_12345 msg="Processing payment"

Когда нужна отладка:

  - Поиск по traceId=trace_12345 в логах всех сервисов
  - Полная цепочка: API → OrderService → Kafka → PaymentService → логи

Логирование ошибок:

При обработке сообщения:
  try {
    process(message);
  } catch (Exception e) {
    log.error("Failed to process message",
      "traceId", message.getTraceId(),
      "messageId", message.getId(),
      "error", e.getMessage(),
      "stackTrace", e);
    deadLetterQueue.send(message);
  }

Алерты

Алерты сообщают инженерам о проблемах.

Типичные алерты:

1. Растущий Lag:

   - Условие: lag растёт более 1000 сообщений в минуту
   - Действие: добавить консьюмеров или оптимизировать обработку

2. Растущий DLQ:

   - Условие: в DLQ появилось 10+ сообщений за час
   - Действие: расследовать причину, посмотреть ошибки

3. Консьюмер не работает:

   - Условие: no messages processed за 5 минут
   - Действие: проверить консьюмер, перезагрузить

4. Брокер упал:

   - Условие: брокер недоступен
   - Действие: критический alert, восстанавливать услугу

5. Недостаточно хранилища:

   - Условие: хранилище брокера > 80% полно
   - Действие: добавить дисковое пространство или удалить старые сообщения

На собеседовании: «Мы мониторим lag каждой consumer group. Если lag растёт свыше 10k сообщений, срабатывает alert. Мы также мониторим DLQ: если там появляется 5+ сообщений, это critical alert, потому что это означает ошибку обработчика. Все события с traceId логируются, что позволяет отследить цепочку от исходного запроса через все микросервисы».

Как Упомянуть Observability на System Design

Звучит так: «Для observability мы:

1. Добавим correlation ID к каждому сообщению, что позволит отследить запрос через все сервисы
2. Будем мониторить lag: если lag > 10k, значит консьюмер отстаёт
3. Будем отслеживать количество сообщений в DLQ: рост означает ошибку в обработчике
4. Запустим дашборд в Grafana с графиками: lag по каждой consumer group, частота ошибок, latency обработки
5. Настроим алерты: если lag растёт, если DLQ растёт, если консьюмер мёртв

Это даст нам видимость в здоровье event-driven части системы».

Очереди и Java Backend

Клиенты для Брокеров

При работе с очередями в Java используются специализированные клиенты.

Kafka (KafkaProducer / KafkaConsumer):

// Продюсер
KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("orders", orderId, orderJson));

// Консьюмер
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(List.of("orders"));
for (ConsumerRecord<String, String> record : consumer.poll(Duration.ofMillis(100))) {
  process(record.value());
}
consumer.commitAsync();

Параметры:

Продюсер:

  - acks: how many replicas must acknowledge ("all", "1", "0")
  - retries: number of retries
  - batch.size: batch size in bytes
  - linger.ms: wait time before sending batch

Консьюмер:

  - group.id: consumer group name
  - auto.offset.reset: what to do if no offset ("earliest", "latest", "none")
  - enable.auto.commit: auto-commit offsets
  - session.timeout.ms: time before rebalancing if no heartbeat

RabbitMQ (AMQP):

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.basicPublish("exchange", "routing.key", null, message.getBytes());

// Консьюмер
channel.basicConsume("queue", false, (tag, delivery) -> {
  process(delivery.getBody());
  channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
});

Spring Boot интеграции:

// Spring Kafka
@KafkaListener(topics = "orders", groupId = "payment-service")
public void handleOrderEvent(OrderPlaced event) {
  processPayment(event);
}

@KafkaTemplate
public void publish(OrderPlaced event) {
  kafkaTemplate.send("orders", event);
}

// Spring RabbitMQ (используется редко в микросервисах)
@RabbitListener(queues = "orderQueue")
public void handleOrder(Order order) {
  processOrder(order);
}

Обработчики Сообщений

Обработчик сообщения — это бизнес-логика, которая выполняется при получении сообщения.

Single-threaded обработка (последовательная):

while (true) {
  message = consumer.poll();
  try {
    process(message); // синхронная обработка, может занять 5 сек
  } catch (Exception e) {
    handleError(e);
  }
  consumer.commitAsync();
}

Пропускная способность: 1 / 5 сек = 0.2 msg/sec

Multi-threaded обработка (параллельная):

ExecutorService executor = Executors.newFixedThreadPool(50);

while (true) {
  List<Message> batch = consumer.poll(Duration.ofMillis(100)); // batch из 100 сообщений
  for (Message message : batch) {
    executor.submit(() -> {
      try {
        process(message);
        consumer.commitAsync();
      } catch (Exception e) {
        handleError(e);
      }
    });
  }
}

Пропускная способность: 50 * (1 / 5 сек) = 10 msg/sec

Spring Kafka по умолчанию использует multi-threaded обработку (параметр concurrency):

spring.kafka.listener.concurrency=50

Влияние бизнес-логики на throughput:

Бизнес-логика 1: валидировать заказ (быстро, 1ms)
  - Потенциальный throughput с 50 потоками: 50k msg/sec

Бизнес-логика 2: вызвать внешнее API (медленно, 500ms)
  - Потенциальный throughput с 50 потоками: 100 msg/sec

Вывод: throughput зависит от бизнес-логики, не только от числа потоков

Idempotent Handlers

Идемпотентные обработчики — это обработчики, которые безопасно обрабатывать один и тот же запрос дважды.

Минус (не идемпотентный):

public void handlePaymentProcessed(PaymentEvent event) {
  balance += event.getAmount(); // если придёт дважды, баланс += 2x
  userRepository.save(user);
}

Плюс (идемпотентный):

public void handlePaymentProcessed(PaymentEvent event) {
  // Подход 1: проверить, был ли обработан
  if (isProcessed(event.getPaymentId())) {
    return; // уже обработано, пропустить
  }
  
  // Подход 2: использовать upsert
  Payment payment = new Payment(event.getPaymentId(), event.getAmount());
  paymentRepository.upsert(payment); // INSERT ON CONFLICT UPDATE
  
  // Подход 3: использовать естественный ключ с уникальным индексом
  user.addTransaction(new Transaction(event.getPaymentId(), event.getAmount()));
  userRepository.save(user);
}

На практике в Spring Boot:

@KafkaListener(topics = "payments", groupId = "balance-service")
@Transactional
public void handlePayment(PaymentProcessed event) {
  // Проверить, был ли обработан
  Optional<ProcessedPayment> existing = processedPaymentRepository
    .findByPaymentId(event.getPaymentId());
  if (existing.isPresent()) {
    return; // идемпотентность: повторная обработка ничего не делает
  }
  
  // Обработать и записать в БД
  ProcessedPayment record = new ProcessedPayment(event.getPaymentId(), event.getAmount());
  processedPaymentRepository.save(record); // сохранить для идемпотентности
  
  // Обновить баланс
  User user = userRepository.findById(event.getUserId());
  user.addBalance(event.getAmount());
  userRepository.save(user);
}

Как на Собеседовании Говорить про Java-практику

Звучит так: «Для обработки событий мы используем Spring Kafka с 50 потоками обработки. Каждый обработчик читает сообщение, обрабатывает его (например, обновляет баланс в БД), и отправляет ack. Обработчик спроектирован как идемпотентный: первый раз платёж обрабатывается, второй раз он проверяет, был ли уже обработан по paymentId, и пропускает обработку. Это гарантирует, что при at-least-once доставке система остаётся корректной. Если обработка падает с исключением, сообщение переигрывается, а если после 3 ретраев всё ещё не работает, оно отправляется в DLQ».

Чек-лист Обсуждения Очередей и Стриминга на System Design

Вот структурированный подход к обсуждению event-driven части системы на собеседовании:

Какие Пункты Обязательно Покрыть

1. Зачем нужен брокер в данной системе:

Начить с очевидного: почему очередь подходит лучше, чем синхронный вызов?

Ответ:

• Эта операция может быть медленной, и не нужно блокировать исходный запрос
• Может быть пик нагрузки, который нужно буферизировать
• Нужна слабая связанность между сервисами
• Нужна надёжность: даже если downstream-сервис упал, сообщение будет сохранено

Примеры:

• OrderService → отправить OrderPlaced → брокер → несколько подписчиков (Notification, Payment, Inventory)
• Синхронный вызов OrderService → PaymentService: если PaymentService упал, весь заказ падает

2. Модель использования (очереди vs стриминг, point-to-point vs pub/sub):

Очень важно артикулировать различие:

• Очередь (RabbitMQ): point-to-point, message удаляется после обработки
• Стриминг (Kafka): pub/sub, events остаются, множество подписчиков

Ответ:

• Для OrderPlaced нам подходит топик (Kafka), потому что несколько разных сервисов (Notification, Payment, Inventory) должны получить одно событие, и могут присоединяться новые подписчики
• Для распределённых задач обработки изображений нам подходит очередь (RabbitMQ), потому что каждую задачу должен обработать ровно один воркер

3. Delivery semantics и идемпотентность обработчиков:

Это ключевой пункт, показывающий глубокое понимание:

• Мы используем at-least-once доставку, потому что потеря события недопустима
• Это означает, что событие может прийти дважды
• Поэтому обработчик спроектирован как идемпотентный: используем upsert в БД или проверяем processed-ID

4. Партиционирование и порядок:

Объяснить, как достигается порядок и масштабируемость одновременно:

• Топик имеет 50 партиций
• Все события для одного userId имеют partition key = userId, поэтому попадают в одну партицию
• Это гарантирует порядок событий для одного пользователя
• 50 партиций обрабатываются 50 консьюмерами параллельно, что даёт масштабируемость

5. DLQ и стратегия обработки ошибок:

Показать понимание, что не все сообщения успешно обрабатываются:

• Если обработка падает с исключением, консьюмер пытается повторить 3 раза с exponential backoff
• Если все попытки исчерпаны, сообщение отправляется в DLQ
• Отдельный процесс мониторит DLQ и алертирует инженеров
• Инженер расследует причину (например, неверный формат сообщения) и переигрывает из DLQ после фиксации

6. Как очереди помогают с пиками нагрузки и backpressure:

Практический пример:

• Без очереди: в час пик 10x нагрузка → нужно 10x больше ресурсов воркеров → затраты
• С очередью: нагрузка буферизируется в очереди, 100 консьюмеров обрабатывают в своём темпе, всё обрабатывается за 2 часа вместо 20 минут

7. Как мониторятся и масштабируются консьюмеры:

Завершить описанием observability и операционной части:

• Мониторим lag: если lag > 10k, добавляем консьюмеров
• Мониторим DLQ: если растёт, критический alert
• Correlation ID в логах позволяет отследить цепочку запроса через все сервисы

Пример Краткого Структурированного Ответа

Как вписать очереди в любую design-задачу:

«Для интеграции сервисов мы используем асинхронное взаимодействие через Kafka.

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

- OrderService создаёт заказ, публикует OrderPlaced в Kafka
- TopicOrderPlaced имеет 50 партиций, каждая реплицируется на 3 ноды
- Partition key = orderId, гарантирует порядок событий для одного заказа
- 50 консьюмеров в каждой consumer group (NotificationService, PaymentService, InventoryService) обрабатывают параллельно

Надёжность:

- at-least-once доставка: события не потеряются
- Обработчики идемпотентны: используем natural key (orderId) в БД, upsert гарантирует идемпотентность
- Outbox pattern для OrderService: событие записывается в outbox вместе с заказом в одной транзакции, гарантирует публикацию

Обработка ошибок:

- Если PaymentService не может обработать платёж: 3 ретрая с exponential backoff
- Если все ретраи исчерпаны: отправляем в DLQ
- Отдельный мониторинг DLQ: alert если сообщения появились

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

- При пике нагрузки 10x: Kafka буферизирует 500k заказов в очереди
- Консьюмеры обрабатывают в своём темпе, очередь не переполняется
- Lag мониторится: при lag > 50k автоскейлер добавляет консьюмеров

Мониторинг:

- Correlation ID в каждом событии для трассировки
- Grafana дашборд: lag по партициям, frequency ошибок, latency обработки
- Алерты: если lag растёт, если DLQ растёт, если консьюмер мёртв
»

Типичные Ошибки Кандидатов при Обсуждении Очередей и Стриминга

Ошибка 1: «Магическая Kafka»

Минус:

Мы используем Kafka для решения этой проблемы.

Интервьюер думает: кандидат не объяснил, почему именно Kafka и как она решит задачу.

Плюс:

Для асинхронной интеграции между сервисами мы используем Kafka. Она позволяет OrderService опубликовать OrderPlaced, а NotificationService, PaymentService и InventoryService независимо читают это событие. Это дает нам слабую связанность и позволяет добавлять новые потребители без изменения OrderService. Кроме того, Kafka буферизирует события, если PaymentService временно недоступен, события не потеряются.

Ошибка 2: Игнорирование Delivery Semantics

Минус:

Мы публикуем событие в Kafka, и потребитель его обрабатывает.

Интервьюер думает: кандидат не знает, что может быть дублирование или потеря.

Плюс:

Мы используем at-least-once доставку, что означает, что событие может прийти дважды. Чтобы система оставалась корректной, каждый обработчик идемпотентен: для платежа мы используем upsert по paymentId, второе получение того же платежа просто игнорируется.

Ошибка 3: Отсутствие Стратегии Обработки Ошибок

Минус:

Если обработчик падает, мы просто логируем и забываем.

Интервьюер думает: какие сообщения теряются? как оператор узнает о проблеме?

Плюс:

Если консьюмер не может обработать сообщение, он пытается 3 раза с exponential backoff (100ms, 200ms, 400ms). Если все попытки не удались, сообщение отправляется в DLQ. Отдельный процесс мониторит DLQ, и при появлении сообщений срабатывает critical alert. Инженер смотрит логи и может переиграть сообщение после фиксации.

Ошибка 4: Непонимание Разницы между Очередью и Логом Событий

Минус:

Мы используем Kafka как очередь для распределённой обработки задач.

Интервьюер думает: Kafka не очередь, это лог событий. Кандидат путает концепции.

Плюс:

Для обработки фоновых задач мы используем RabbitMQ как точку-в-точку очередь, где каждая задача обрабатывается ровно одним воркером. Для асинхронной интеграции между сервисами мы используем Kafka как событийный лог, где множество потребителей читают одно событие независимо.

Ошибка 5: Перегрузка Buzzword'ами без Связи с Требованиями

Минус:

Мы используем Event Sourcing, CQRS и Kafka для достижения согласованности.

Интервьюер думает: кандидат просто перечисляет buzzword'ы, не объясняя, почему это нужно для конкретной задачи.

Плюс:

Для отчётов в реальном времени мы используем CQRS: OrderService (Command Side) обрабатывает команды PlaceOrder, генерирует события OrderPlaced. ReportingService (Query Side) слушает события и обновляет Elasticsearch для быстрого поиска. Это даёт нам отчёты в реальном времени без перегрузки основной БД. Event sourcing мы не используем, потому что OrderService не требует полной истории всех событий, только текущее состояние.

Рекомендации, Как Звучать как Senior

1. Объяснять Trade-offs:

Не просто говорить про функциональность, но про компромиссы:

• at-least-once доставка требует идемпотентности обработчиков (trade-off: сложность за надёжность)
• Гарантирование порядка требует 1 партиции (trade-off: порядок за масштабируемость)
• Высокий replication factor требует больше ресурсов (trade-off: надёжность за ресурсы)

2. Говорить о Числах:

Интервьюеры ценят кандидатов, которые думают в масштабах:

• «Если у нас 1000 заказов в секунду и каждый обработчик может обработать 100 заказов в секунду, нам нужно 10 потоков обработки»
• «DLQ может расти на 1000 сообщений в минуту при ошибке, это потребует масштабирования»

3. Упоминать Operability:

Senior инженер думает не только о функциональности, но и о том, как это поддерживать:

• Мониторинг lag, DLQ, latency
• Алерты для критичных ситуаций
• Runbook для общих проблем (lag растёт, DLQ растёт, консьюмер мёртв)

4. Показывать Опыт:

Рассказывать о реальных проблемах, которые встречались:

• «В production был инцидент, когда один пользователь генерировал 1 млн сообщений в секунду (hot key), это перегрузило одну партицию. Мы добавили композитный partition key, чтобы распределить нагрузку».
• «Мы упустили, что консьюмеры работают медленнее ожидаемого, lag вырос до 500k за ночь. Добавили больше потоков обработки».

Транзакции

Введение: Почему консистентность критична

В монолитных системах с единой базой данных консистентность гарантируется ACID-транзакциями на уровне СУБД. При разбиении системы на микросервисы с собственными хранилищами появляется сетевая граница, которая вносит принципиальные ограничения.

Сетевые ограничения в распределённых системах

На каждом этапе межсервисного взаимодействия может произойти:

• Задержка (латенция): ответ идёт не мгновенно, типичные значения 1–100 мс в локальной сети, 100–500 мс между дата-центрами
• Недоступность сервиса: один сервис временно не отвечает, вызов зависает до истечения timeout
• Частичный отказ: часть инфраструктуры упала, система продолжает частично работать

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

Бизнес-последствия неправильной консистентности

Недоработанная консистентность приводит к реальным потерям:

Основные понятия

Бизнес-инварианты

Бизнес-инвариант — это условие, которое всегда должно быть истинным в согласованном состоянии системы.

Примеры инвариантов:

• Баланс счёта ≥ 0 (в консервативных системах)
• Заказ находится в одном и только в одном статусе из набора {создан, оплачен, отправлен, доставлен, отменён}
• Количество товара на складе ≥ 0
• Администратор не может удалить организацию, если он единственный активный администратор

На этапе проектирования архитектуры нужно определить:

1. Какие инварианты обязательно требуют немедленного выполнения (strong consistency)
2. Какие инварианты могут быть нарушены на короткое время (eventual consistency)
3. Как система будет восстанавливаться при нарушении инварианта

Локальная vs глобальная консистентность

Локальная консистентность: гарантируется внутри одного сервиса в его БД через ACID-транзакции. Например, Account Service гарантирует консистентность баланса внутри своей БД.

Глобальная консистентность: согласованность данных между несколькими сервисами. Пример: при создании заказа нужно синхронизировать состояние в Order Service, Inventory Service, Payment Service, Notification Service.

Ключное понимание: глобальный ACID между сервисами недостижим из-за сетевых ограничений. Вместо этого используются паттерны для достижения глобальной консистентности на уровне бизнес-процессов.

ACID и BASE

Модели консистентности

Strong Consistency (Сильная консистентность)

Определение: все клиенты видят одно и то же состояние данных сразу после записи.

Гарантия: после возврата успешного ответа клиенту, все последующие чтения вернут обновленные данные.

Где требуется:

• Финансовые операции (переводы, платежи): баланс не должен быть отрицательным ни в какой момент
• Критичные ресурсы (билеты, места в отеле): один ресурс не может быть продан дважды
• Юридически значимые операции (контракты, соглашения)

Механизмы реализации:

• Синхронные вызовы между сервисами (REST/gRPC с ожиданием ответа)
• Глобальные распределённые транзакции (2PC, 3PC)
• Блокировка ресурсов на время операции

Стоимость:

Типичные значения для strong consistency в микросервисном контексте:

• P50 latency: 50–200 мс (в зависимости от количества сервисов)
• P99 latency: 500–2000 мс
• Throughput: 100–1000 операций/сек на один инстанс

Eventual Consistency (Консистентность в конечном итоге)

Определение: данные не гарантируют быть одинаковыми сразу после записи, но через некоторое время все запросы вернут одно состояние.

Типичная временная шкала:

• Оптимистичный случай: 1–10 мс (если события обрабатываются на том же сервере)
• Нормальный случай: 50–500 мс (события через Kafka)
• Пессимистичный случай: 1–5 сек (перегруженная система, многоуровневая обработка)

Где достаточно:

• Статистика и счетчики (лайки, просмотры, комментарии)
• Ленты и рекомендации (актуальность за часы, не за миллисекунды)
• Нотификации (задержка в несколько секунд приемлема)
• Кэши и денормализованные данные

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

Типичные значения для eventual consistency:

• P50 latency: 1–50 мс
• P99 latency: 50–500 мс
• Throughput: 10000+ операций/сек на один инстанс

Промежуточные модели

Read-your-writes: после записи пользователя его последующие чтения видят его же изменения, но другие пользователи могут видеть старые данные временно.

Применение: профили пользователей, черновики документов, персональные настройки.

Механизм: sticky routing (маршрутизация одного пользователя на одну реплику) или клиентское кэширование.

Monotonic reads: если вы прочитали версию A объекта, затем версию B, вы не вернётесь к версии A. Движение только вперёд.

Применение: ленты активности, логи событий.

Механизм: гарантия порядка обработки событий, маршрутизация на основе версии.

Monotonic writes: если вы записали изменение A, затем B, все системы увидят A раньше B.

Применение: критичные последовательности операций.

Механизм: версионирование записей, логирование.

Распределённые системы и частичные отказы

Типы отказов в распределённой системе

Сетевая задержка (latency):

• Запросы идут по сети → могут задержаться на 1–100+ мс
• Причины: перегруженные каналы, расстояние, маршруизирование, перегруженные коммутаторы
• Нет способа узнать точное время доставки заранее

Потеря пакетов:

• Несмотря на TCP гарантиям, на уровне приложения пакеты могут быть потеряны
• Причины: переполнение буферов, ошибки оборудования, сброс соединения
• Решение: retry логика с exponential backoff

Network partitioning (разделение сети):

• Часть системы отключена от другой части из-за сбоя маршрутизатора, провайдера или кабеля
• Получается два независимых "острова" сервисов
• Каждый остров может работать, но синхронизация невозможна
• Решение: выбрать, какой остров "выживает", другой переходит в read-only режим

Частичный отказ

В монолите: либо приложение работает, либо вообще не работает.

В микросервисной архитектуре: одновременно могут быть доступны одни сервисы и недоступны другие.

Пример:

Order Service: ✓ работает
Payment Service: ✓ работает  
Inventory Service: ✗ упал
Notification Service: ✗ недоступна (за firewall)

Последствия:

• Операция может быть выполнена частично (заказ создан, но товар не зарезервирован)
• Ресурсы могут зависнуть на одном из сервисов (lock удерживает БД)
• Каскадный отказ: если Service A ждёт ответа от Service B, который упал, то потоки А заполняются, и А начинает отвечать медленнее или падает

Расчёт вероятности успешной операции

Если операция затрагивает N сервисов, каждый с доступностью Ai:

Общая доступность = A1 × A2 × ... × AN

Пример: 3 сервиса, каждый с 99.9% доступностью:

Общая доступность = 0.999 × 0.999 × 0.999 = 0.997 (99.7%)
Downtime в год = 365 × 24 × 60 × (1 - 0.997) = 1576 минут (~26 часов)

Вывод: с ростом количества сервисов доступность системы падает. Это создаёт давление на использование асинхронных паттернов (eventual consistency), чтобы избежать синхронной зависимости между всеми сервисами.

Классические распределённые протоколы

Two-Phase Commit (2PC)

Структура:

Координатор и N участников (БД, очереди). Цель: гарантировать, что либо все участники выполнят операцию, либо все откатят.

Фаза 1: Prepare (Vote)

1. Координатор отправляет всем участникам: "Готовы ли вы выполнить операцию X?"

2. Каждый участник:

   • Пытается выполнить операцию
   • Блокирует необходимые ресурсы (строки, таблицы)
   • Записывает в лог: "Готов" или "Не готов"
   • Не коммитит, оставляя блокировку активной
   • Отвечает координатору

Фаза 2: Commit/Abort

• Если все ответили "Готов", координатор отправляет "Коммитьте!"
• Все участники коммитят и освобождают блокировки
• Если хоть один ответил "Не готов", координатор отправляет "Откатьте!"
• Все откатывают, блокировки освобождаются

Визуализация:

Время   Координатор    БД1 (Account)        БД2 (Inventory)
T0      Prepare?       ──────────────→
T5                     Блокирует счёт A
T6                     "Готова"      ←──────
T7      Prepare?                               ──────────────→
T10                                           Блокирует товар
T11                                           "Готова"      ←──────
T12     Commit!        ──────────────→
T13                    Коммитит
T14                    Освобождает   ←──────
T15     Commit!                               ──────────────→
T16                                           Коммитит
T17                                           Освобождает   ←──────

Проблемы 2PC:

Типичные метрики для 2PC:

• Latency: 100–500 мс (в идеальном случае), 2–5 сек (в реальности)
• Throughput: 10–100 транзакций/сек на один координатор
• Надёжность: 99% в хорошей сети, 95% в интернете

Three-Phase Commit (3PC)

3PC пытается улучшить 2PC, добавив третью фазу — Pre-commit.

Фазы:

1. Prepare: как в 2PC, но координатор НЕ коммитит сразу
2. Pre-commit: координатор отправляет "Я получил готовность от всех, готовьтесь к коммиту"
3. Commit: финальный коммит

Идея: если координатор упадёт после Pre-commit, участники знают, что нужно коммитить (потому что Phase 2 пройдена). Если упадёт на Prepare, все откатывают.

Реальность: 3PC не решает главную проблему — network partitioning. Это доказано в FLP impossibility theorem: в асинхронной сети с потерями нет алгоритма, который гарантирует консенсус при любых сбоях.

На практике 3PC почти не используется, потому что:

• Добавляет дополнительный раунд сетевых запросов (ещё +100 мс latency)
• Всё равно не решает проблему partitioning
• Сложнее реализовать и поддерживать

Почему уходят от 2PC/3PC в микросервисах

В современных микросервисных архитектурах 2PC/3PC используются редко, потому что:

1. Требуют синхронной координации между многими сервисами → низкая throughput
2. Имеют single point of failure → низкая надёжность
3. Не работают при network partitioning → проблемы в production
4. Требуют, чтобы все сервисы поддерживали протокол → tight coupling

Вместо этого используют локальные транзакции + асинхронные паттерны (Saga, Outbox).

Локальные транзакции и границы консистентности

Принцип: один сервис, одна БД, одна локальная транзакция

Это фундаментальный принцип микросервисной архитектуры:

• Каждый микросервис владеет только своей БД
• Другие сервисы не имеют прямого доступа к его БД
• Взаимодействие идёт через API (REST/gRPC) или события
• Каждый сервис может выбрать любую БД (PostgreSQL, MongoDB, Cassandra)

Следствие: каждый сервис может гарантировать консистентность только своих данных через локальные ACID-транзакции. Глобальная консистентность достигается через протоколы взаимодействия.

Определение границ сервиса

1. Bounded context (Domain-Driven Design)

Область, в которой действуют единые правила и определения:

• Account Service: знает про счета, платежи, валюты, балансы
• Order Service: знает про заказы, статусы заказов, позиции
• Inventory Service: знает про товары, количество на складе, резервы

Границы между контекстами — это точки, где нужна координация через протоколы (Saga, события).

2. Инварианты

Какие ограничения должны быть гарантированно выполнены в пределах одного сервиса?

• Account Service гарантирует: баланс ≥ 0
• Order Service гарантирует: заказ в одном из допустимых статусов
• Inventory Service гарантирует: количество ≥ 0

3. Данные

Какие таблицы/коллекции входят в этот сервис? Всё остальное — чужая ответственность.

Saga Pattern

Концепция

Saga — это долгоживущая бизнес-операция, разбитая на цепочку локальных шагов. Каждый шаг — локальная ACID-транзакция в одном сервисе. Если шаг не удаётся, запускаются компенсирующие действия для отката уже выполненных шагов.

Гарантия: либо все шаги выполнены успешно, либо система возвращена в согласованное состояние через компенсацию.

Orchestration vs Choreography

Orchestration (Оркестрация)

Архитектура: есть центральный Saga Orchestrator (отдельный сервис или компонент), который:

• Получает команду (например, CreateOrder)
• Отправляет команды другим сервисам в определённом порядке
• Ждёт ответов
• Решает, двигаться дальше или откатываться

Поток:

OrderOrchestrator
  ├─ [Шаг 1] Отправить InventoryService: "Зарезервируй товар X"
  │           Ждать ответ
  │           ✓ Успех → ReservationId=12345
  │
  ├─ [Шаг 2] Отправить PaymentService: "Зарезервируй платёж"
  │           Ждать ответ
  │           ✗ Ошибка (нет денег)
  │
  └─ [Отмена] Отправить InventoryService: "Отмени резерв 12345"
             Вернуть ошибку клиенту

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

• Явный поток (легко проследить логику в коде)
• Просто добавить логирование и мониторинг
• Возможность добавить условную логику

Недостатки:

• Orchestrator — point of failure (если упадёт, Saga зависнет)
• Orchestrator должен знать про все сервисы → тесная связанность
• Если Orchestrator недоступен, новые Sagas не начнут

Метрики:

• Latency: сумма latencies всех шагов + координационные задержки
  • Типично: 500 мс–2 сек для 3–5 шагов
• Throughput: ограничен одним Orchestrator
  • Один инстанс: 100–500 Sagas/сек
  • Кластер: масштабируется до 10000+ Sagas/сек с load balancing

Choreography (Хореография)

Архитектура: нет центрального координатора. Каждый сервис слушает события из брокера и реагирует.

Поток:

1. User Service создаёт заказ, публикует: OrderCreated
2. Inventory Service слушает OrderCreated
   → резервирует товар
   → публикует: InventoryReserved
3. Payment Service слушает InventoryReserved
   → резервирует платёж
   → если успех: публикует PaymentReserved
   → если ошибка: публикует PaymentFailed
4. Inventory Service слушает PaymentFailed
   → отменяет резерв
   → публикует: InventoryCancelled
5. Order Service слушает PaymentReserved
   → обновляет статус на "confirmed"
   → публикует: OrderConfirmed

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

• Слабая связанность (сервисы не знают друг о друге)
• Масштабируется лучше (нет центральной координации)
• Естественная event-driven архитектура
• Легко добавлять новые этапы (новый сервис просто слушает события)

Недостатки:

• Сложнее проследить поток (события летят в разные стороны)
• Труднее отладить — нужно мокировать много событий
• Может быть сложнее гарантировать порядок событий
• "Event spaghetti" — непонятная последовательность обработки

Метрики:

• Latency: параллельная обработка, потенциально быстрее чем Orchestration
  • Типично: 200 мс–1 сек
• Throughput: масштабируется лучше
  • 1000–5000+ Sagas/сек в распределённой системе

Сравнение паттернов

Пример: Создание заказа

Требования:

• Зарезервировать товар
• Зарезервировать платёж
• Создать заказ
• Отправить уведомление

Orchestration вариант (Order Service содержит Orchestrator):

@Service
@Transactional
public class OrderOrchestrator {
    
    @Autowired private OrderRepository orderRepository;
    @Autowired private InventoryServiceClient inventoryClient;
    @Autowired private PaymentServiceClient paymentClient;
    @Autowired private NotificationServiceClient notificationClient;
    
    public Order createOrder(CreateOrderCommand cmd) {
        // Шаг 1: Зарезервировать товар
        ReservationResponse inventoryRes = inventoryClient.reserve(
            cmd.getProductId(), 
            cmd.getQuantity()
        );
        if (!inventoryRes.isSuccess()) {
            throw new BusinessException("Товар недоступен");
        }
        String reservationId = inventoryRes.getReservationId();
        
        try {
            // Шаг 2: Зарезервировать платёж
            PaymentResponse paymentRes = paymentClient.reserve(
                cmd.getAmount()
            );
            if (!paymentRes.isSuccess()) {
                // Компенсация: отмена резерва товара
                inventoryClient.cancelReservation(reservationId);
                throw new BusinessException("Недостаточно средств");
            }
            String paymentId = paymentRes.getPaymentId();
            
            // Шаг 3: Создать заказ (локальная транзакция)
            Order order = Order.builder()
                .userId(cmd.getUserId())
                .inventoryReservationId(reservationId)
                .paymentReservationId(paymentId)
                .status(OrderStatus.CONFIRMED)
                .build();
            orderRepository.save(order);
            
            // Шаг 4: Отправить уведомление (некритично, best effort)
            notificationClient.sendAsync(
                "order.created",
                order.getId()
            );
            
            return order;
            
        } catch (Exception e) {
            // Если что-то пошло не так, компенсируем
            inventoryClient.cancelReservation(reservationId);
            throw e;
        }
    }
}

Choreography вариант (события между сервисами):

// OrderService
@Service
public class OrderService {
    @Autowired private OrderRepository orderRepository;
    @Autowired private KafkaTemplate<String, OrderEvent> kafkaTemplate;
    
    public void createOrder(CreateOrderCommand cmd) {
        Order order = Order.builder()
            .userId(cmd.getUserId())
            .status(OrderStatus.PENDING)
            .build();
        orderRepository.save(order);
        
        kafkaTemplate.send("order-events", "OrderCreated", 
            new OrderCreatedEvent(order.getId(), cmd.getProductId(), cmd.getQuantity())
        );
    }
}

// InventoryService
@Service
public class InventoryConsumer {
    @Autowired private InventoryRepository inventoryRepository;
    @Autowired private KafkaTemplate<String, InventoryEvent> kafkaTemplate;
    
    @KafkaListener(topics = "order-events", groupId = "inventory-group")
    public void handleOrderCreated(OrderCreatedEvent event) {
        boolean reserved = inventoryRepository.reserve(
            event.getProductId(), 
            event.getQuantity()
        );
        
        if (reserved) {
            kafkaTemplate.send("inventory-events", "InventoryReserved",
                new InventoryReservedEvent(event.getOrderId())
            );
        } else {
            kafkaTemplate.send("inventory-events", "InventoryReservationFailed",
                new InventoryReservationFailedEvent(event.getOrderId())
            );
        }
    }
}

// PaymentService
@Service
public class PaymentConsumer {
    @Autowired private PaymentRepository paymentRepository;
    @Autowired private KafkaTemplate<String, PaymentEvent> kafkaTemplate;
    
    @KafkaListener(topics = "inventory-events", groupId = "payment-group")
    public void handleInventoryReserved(InventoryReservedEvent event) {
        Payment payment = Payment.builder()
            .orderId(event.getOrderId())
            .status(PaymentStatus.RESERVED)
            .build();
        
        if (paymentRepository.hasBalance(payment)) {
            paymentRepository.save(payment);
            kafkaTemplate.send("payment-events", "PaymentReserved",
                new PaymentReservedEvent(event.getOrderId())
            );
        } else {
            // Kompensation: отмена резерва товара
            kafkaTemplate.send("order-events", "PaymentFailed",
                new PaymentFailedEvent(event.getOrderId())
            );
        }
    }
}

TCC (Try-Confirm-Cancel)

Структура

TCC — это более строгий протокол, требующий от каждого участника реализовать три операции:

Try: подготовка и резервирование ресурса

• Заблокировать ресурс в БД (деньги, товар)
• Проверить, возможна ли операция
• Оставить ресурс зарезервированным (в специальном состоянии)
• Вернуть успех/ошибку

Confirm: окончательная фиксация

• Окончательно применить изменения (вычесть деньги, уменьшить количество)
• Освободить ресурс из состояния резервирования

Cancel: отмена

• Освободить зарезервированный ресурс
• Вернуть в исходное состояние

Взаимодействие

Coordinator: "Try? Зарезервируй 100 руб со счёта A"
Account Service:

  - Проверяет: баланс >= 100? Да
  - Помещает 100 в "frozen" (зарезервировано)
  - Отвечает: "OK, зарезервировано"

Coordinator: "Try? Зарезервируй 2 шт товара X"
Inventory Service:

  - Проверяет: количество >= 2? Да
  - Помещает 2 в "reserved"
  - Отвечает: "OK, зарезервировано"

Coordinator: "Все Try успешны, Confirm!"

Account Service:

  - Вычитает 100 из основного баланса
  - Удаляет из "frozen"

Inventory Service:

  - Вычитает 2 из основного количества
  - Удаляет из "reserved"

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

Подходит:

• Критичные финансовые операции (переводы, платежи)
• Когда нужна strong consistency между несколькими сервисами
• Когда компенсирующие действия сложные или дорогие

Недостатки:

• Требует явной реализации трёх операций в каждом сервисе
• Более сложен в разработке, чем Saga
• Требует дополнительной логики резервирования в БД
• Все участники должны быть доступны (иначе блокируется)

Метрики:

• Latency: 200–1000 мс (3 раунда сетевых запросов)
• Throughput: 50–200 операций/сек на один Coordinator
• Успешность: зависит от доступности всех участников

Outbox Pattern: Гарантированная публикация событий

Проблема двух систем

Когда есть две отдельные системы (БД и брокер сообщений), возникают проблемы:

Сценарий 1: БД успешна, Kafka падает
  INSERT INTO orders VALUES (1, 'pending') ✓
  PUBLISH TO kafka: OrderCreated            ✗
  
Результат: заказ в БД, но события нет → консюмеры ничего не знают

Сценарий 2: БД падает, Kafka успешна
  INSERT INTO orders VALUES (2, 'pending') ✗ (откат)
  PUBLISH TO kafka: OrderCreated            ✓
  
Результат: события прошли, но заказа в БД нет → консюмеры попытаются обновить несуществующий заказ

Решение: Outbox Pattern

Идея: не публиковать событие напрямую. Вместо этого:

1. Одна локальная транзакция:

   • Сохранить бизнес-данные в таблицу
   • Сохранить событие в таблицу outbox_events
   • Коммит либо оба, либо ничего

2. Отдельный worker (может быть polling job, может быть CDC):

   • Читать новые события из outbox_events
   • Публиковать в Kafka/RabbitMQ
   • Удалять из outbox после успешной публикации

Структура таблиц

-- Основная таблица
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    status VARCHAR,
    created_at TIMESTAMP
);

-- Outbox таблица
CREATE TABLE outbox_events (
    id BIGINT PRIMARY KEY,
    aggregate_id VARCHAR,      -- ID заказа
    event_type VARCHAR,        -- "OrderCreated", "OrderCancelled"
    event_data TEXT,           -- JSON с деталями события
    created_at TIMESTAMP,
    published BOOLEAN DEFAULT FALSE,
    published_at TIMESTAMP NULL
);

-- Индексы для быстрого поиска неопубликованных
CREATE INDEX idx_outbox_published ON outbox_events(published, created_at);

Реализация

@Service
public class OrderService {
    
    @Autowired private OrderRepository orderRepository;
    @Autowired private OutboxRepository outboxRepository;
    
    @Transactional
    public Order createOrder(CreateOrderCommand cmd) {
        // Шаг 1: создать заказ
        Order order = Order.builder()
            .userId(cmd.getUserId())
            .status(OrderStatus.CREATED)
            .build();
        orderRepository.save(order);
        
        // Шаг 2: записать событие в outbox (в той же транзакции!)
        OutboxEvent event = OutboxEvent.builder()
            .aggregateId(order.getId().toString())
            .eventType("OrderCreated")
            .eventData(objectMapper.writeValueAsString(order))
            .createdAt(Instant.now())
            .published(false)
            .build();
        outboxRepository.save(event);
        
        // Коммит транзакции: либо оба сохранены, либо ничего не сохранено
        return order;
    }
}

@Service
public class OutboxPublisher {
    
    @Autowired private OutboxRepository outboxRepository;
    @Autowired private KafkaTemplate<String, String> kafkaTemplate;
    
    @Scheduled(fixedDelay = 1000)  // Каждую секунду
    public void publishOutboxEvents() {
        List<OutboxEvent> unpublished = outboxRepository.findByPublishedFalse();
        
        for (OutboxEvent event : unpublished) {
            try {
                // Опубликовать в Kafka
                kafkaTemplate.send(
                    "order-events",
                    event.getAggregateId(),
                    event.getEventData()
                ).get(5, TimeUnit.SECONDS);
                
                // Отметить как опубликованное
                event.setPublished(true);
                event.setPublishedAt(Instant.now());
                outboxRepository.save(event);
                
            } catch (Exception e) {
                log.error("Failed to publish event: {}", event.getId(), e);
                // Retry на следующем проходе
            }
        }
    }
}

Гарантии Outbox Pattern

At-least-once доставка:

• Событие будет опубликовано минимум один раз
• Если worker упадёт после публикации, но до обновления БД, событие может быть опубликовано дважды

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

Inbox Pattern и идемпотентность

Проблема повторной доставки

Когда потребитель получает событие из Kafka:

1. Получаем событие "OrderCreated"
2. Обрабатываем: создаём платёж в БД
3. Готовим ответ в Kafka
4. Но соединение падает...
5. Kafka думает: "не получил ack, значит переслать ещё раз"
6. Потребитель получает одно и то же событие второй раз

Результат: платёж создан дважды → финансовая ошибка.

Решение: Inbox Pattern

Идея: на стороне потребителя вести таблицу inbox для отслеживания уже обработанных событий.

CREATE TABLE inbox_events (
    id BIGINT PRIMARY KEY,
    event_id VARCHAR UNIQUE,        -- ID события (уникальный ключ)
    event_type VARCHAR,
    event_data TEXT,
    processed BOOLEAN DEFAULT FALSE,
    processed_at TIMESTAMP NULL,
    received_at TIMESTAMP
);

CREATE INDEX idx_inbox_event_id ON inbox_events(event_id);
CREATE INDEX idx_inbox_processed ON inbox_events(processed);

Реализация идемпотентности

@Service
public class PaymentConsumer {
    
    @Autowired private InboxRepository inboxRepository;
    @Autowired private PaymentRepository paymentRepository;
    
    @KafkaListener(topics = "order-events", groupId = "payment-service")
    @Transactional
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Шаг 1: проверить inbox
        if (inboxRepository.existsByEventId(event.getId())) {
            log.info("Event already processed: {}", event.getId());
            return;  // Пропускаем повторную обработку
        }
        
        // Шаг 2: обработать событие в транзакции с БД
        Payment payment = Payment.builder()
            .orderId(event.getOrderId())
            .amount(event.getAmount())
            .status(PaymentStatus.RESERVED)
            .build();
        paymentRepository.save(payment);
        
        // Шаг 3: записать в inbox (в той же транзакции!)
        InboxEvent inboxEvent = InboxEvent.builder()
            .eventId(event.getId())
            .eventType(event.getType())
            .eventData(event.toJson())
            .processed(true)
            .processedAt(Instant.now())
            .build();
        inboxRepository.save(inboxEvent);
        
        // Коммит: платёж и запись в inbox — либо оба, либо ничего
    }
}

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

Вариант 1: Уникальный ключ в основной таблице

CREATE TABLE payments (
    event_id VARCHAR PRIMARY KEY,     -- ID события как ключ
    order_id BIGINT,
    amount DECIMAL,
    status VARCHAR,
    created_at TIMESTAMP
);

-- При повторной попытке обработки:

-- INSERT ... будет конфликт на event_id
-- Либо делаем INSERT ... ON CONFLICT DO UPDATE
-- Либо ловим исключение и считаем это OK

Вариант 2: Версионирование

// Если применяем изменение с version:
int updated = paymentRepository.updateIfVersion(
    orderId, 
    newStatus, 
    expectedVersion, 
    expectedVersion + 1
);

if (updated == 0) {
    // Уже был обновлён другим потоком
    log.info("Concurrent update, skipping");
}

Effectively-Once Delivery

Определение и достижимость

Exactly-once: событие обработано ровно один раз, без пропусков и дублей.

Проблема: в распределённой системе это теоретически недостижимо (FLP impossibility). После обработки события, при отправке подтверждения может случиться потеря пакета. Как узнать, был ли он обработан?

Effectively-once: практический компромисс, который выглядит как exactly-once для бизнеса, но внутри может обработать дважды.

Архитектура effectively-once

На стороне отправителя (Outbox):

INSERT INTO orders (id, ...) VALUES (...)
INSERT INTO outbox_events (aggregate_id, event_type, ...) VALUES (...)
COMMIT  -- Both или ничего

• Гарантия: событие либо в БД и outbox, либо ничего
• Гарантия: событие будет опубликовано (worker настойчиво пытается)

На стороне брокера (Kafka):

acks=all          -- Лидер ждёт acks от всех replicas
min.insync.replicas=2  -- Минимум 2 replica должны подтвердить
replication.factor=3   -- 3 копии события

• Гарантия: at-least-once доставка (событие не потеряется)
• Возможность: at-most-once при потере replicas (редкий случай)

На стороне потребителя (Inbox):

SELECT * FROM inbox WHERE event_id = ?
-- Если есть, skip
-- Если нет:
  BEGIN TRANSACTION
    process event
    INSERT INTO inbox VALUES (event_id, ...)
  COMMIT

• Гарантия: одно событие обработано один раз в контексте потребителя
• Даже если Kafka переправит дважды, второй раз будет skip

Результат: Effectively-Once

Sender: "Событие создано и в БД, и в outbox"
Broker: "Событие доставлено ≥1 раз"
Consumer: "Событие обработано ровно один раз"

==> Для пользователя: платёж прошёл один раз

Метрики effectively-once

Eventual Consistency в бизнес-процессах

Дизайн с промежуточными статусами

Вместо скрытого асинхронного обновления, покажите пользователю явные статусы:

Заказ: "создан" → "на проверке" → "принят" → "готов к отправке" → "отправлен"
Платёж: "инициирован" → "обработка" → "зарезервирован" → "подтвержден"
Товар: "в наличии" → "зарезервирован" → "отправлен" → "доставлен"

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

Latency по этапам

Пользователь нажимает "Заказать"
  T=0 мс     → Сразу видит "заказ создан" (Order Service создал запись)
  T=200 мс   → "проверяется" (Inventory Service зарезервировал товар)
  T=500 мс   → "принят" (Payment Service зарезервировал платёж)
  T=1200 мс  → "готов" (все этапы Saga завершены)
  T=2000 мс  → SMS уведомление (Notification Service отправил)

Ключ: каждое состояние представимо и объяснимо. Нет "вот сейчас неизвестно что будет".

Восстановление при ошибках

Если что-то пошло не так на этапе обработки:

"Заказ не может быть принят: истекло время резерва товара"
"Заказ отменён: недостаточно средств"
"Система перепроверяет, пожалуйста, подождите..."

Пользователь видит конкретную причину, что не так.

Репликация и консистентность чтений

Архитектура Primary-Replica

Primary (Master)
  ├─ пишут все данные
  ├─ реплицирует в replicas
  └─ lag: <10 мс (обычно)

Replica 1 (Slave)
  ├─ lag: 50–100 мс от primary
  ├─ можно читать
  └─ может быть переполнена запросами

Replica 2
  ├─ lag: 50–100 мс
  ├─ для analytics/reports
  └─ более чувствительна к lag

Проблемы при чтении из replicas

Пример:

T=0 мс    Пользователь создаёт заказ, пишет в primary
T=10 мс   Запрос вернулся: "Заказ создан"
T=15 мс   Пользователь пытается прочитать заказ из replica
T=20 мс   Replica всё ещё отстаёт, вернула: "Заказ не найден"
T=70 мс   Replica синхронизировалась, теперь видит заказ

Результат: read-your-writes нарушена. Пользователь видит свои изменения исчезнувшими.

Стратегии решения

1. Read-your-writes гарантия:

После записи пользователя его следующие N чтений идут в primary.
Затем можно читать из replicas.

Время жизни гарантии: ~1-2 сек (максимум lag replicas)

2. Sticky маршрутизация:

Пользователь U1 пишет → маршрутируем на primary
Следующие 5 секунд все чтения U1 → маршрутируем на primary
Затем → разрешаем читать из replicas

3. Версионирование:

Запись возвращает version=42
При чтении требуем version >= 42
Replica, если у неё version < 42, ждёт репликации

4. Кэширование на клиенте:

Браузер помнит: "Я создал заказ с ID=123"
При чтении сначала проверяет локальный кэш
Если есть в кэше и свежий → показывает из кэша
Параллельно обновляет из сервера

Стратегия масштабирования чтений

95% операций → читают из replicas (денормализованные, быстрые) 4% критичных → читают из primary (свежие данные) 1% системных → специальная обработка (consistency checks, audits)

Метрики:

Распределённые блокировки

Use case

Распределённая блокировка нужна, когда несколько инстансов одного сервиса конкурируют за:

• Единичное действие (ежедневный batch расчёт зарплаты)
• Уникальность (пользователь создаёт аккаунт один раз, не несколько)
• Ресурс (только один пользователь может зарезервировать последнее место)

Реализация на Redis

@Service
public class BatchService {
    
    @Autowired private RedisTemplate<String, String> redisTemplate;
    @Autowired private SalaryRepository salaryRepository;
    
    @Scheduled(cron = "0 0 * * * *")  // Каждый час
    public void runHourlySalaryBatch() {
        String lockKey = "salary-batch:hourly";
        String lockValue = UUID.randomUUID().toString();
        
        // Пытаемся захватить блокировку на 30 минут
        Boolean acquired = redisTemplate.getConnectionFactory()
            .getConnection()
            .setNX(
                lockKey.getBytes(),
                lockValue.getBytes(),
                Duration.ofSeconds(1800)
            );
        
        if (!acquired) {
            log.info("Another instance is running batch, skipping");
            return;
        }
        
        try {
            performSalaryCalculation();
        } finally {
            // Безопасное удаление (только если значение совпадает)
            String currentValue = (String) redisTemplate.opsForValue().get(lockKey);
            if (lockValue.equals(currentValue)) {
                redisTemplate.delete(lockKey);
            }
        }
    }
}

Leader Election

Выбор одного лидера из N инстансов:

@Service
public class PaymentService {
    
    @Autowired private RedisTemplate<String, String> redisTemplate;
    
    @PostConstruct
    public void becomeLeader() {
        String lockKey = "leader:payment-service";
        
        // Все инстансы пытаются
        Boolean leader = redisTemplate.getConnectionFactory()
            .getConnection()
            .setNX(
                lockKey.getBytes(),
                myInstanceId.getBytes(),
                Duration.ofSeconds(10)  // Timeout
            );
        
        if (leader) {
            this.isLeader = true;
            startLeaderTasks();
        }
    }
    
    @Scheduled(fixedDelay = 5000)
    public void refreshLeadership() {
        if (isLeader) {
            String lockKey = "leader:payment-service";
            // Обновляем timeout (refresh lock)
            redisTemplate.expire(lockKey, Duration.ofSeconds(10));
        }
    }
}

Проблемы и решения

Выбор подхода в зависимости от требований

Матрица решений

Дерево решений

Нужна ли МГНОВЕННАЯ консистентность во всей системе?
├─ ДА → Финансовый домен?
│       ├─ ДА → TCC или 2PC (сложнее, но сильнее)
│       └─ НЕТ → Saga + Orchestration
│
└─ НЕТ → Этапов в процессе больше 2?
         ├─ ДА → Saga + Choreography
         └─ НЕТ → Простой асинхронный вызов + Outbox

Калькулятор выбора

Для принятия решения оцените:

1. Количество сервисов в операции: N

   • N ≤ 2 → синхронные вызовы (если < 100 мс)
   • N > 2 → асинхронные (Saga)

2. Требуемая latency: L мс

   • L < 100 → synchronous (REST/gRPC)
   • 100 < L < 1000 → asynchronous (Saga)
   • L > 1000 → batch/eventual

3. Допустимый lag: G мс

   • G < 100 → strong consistency
   • 100 < G < 1000 → eventual consistency
   • G > 1000 → eventual consistency с сильным lag

4. Стоимость ошибки: C

   • C > $1000 → strong consistency обязательна
   • $100–1000 → Saga с компенсацией
   • C < $100 → eventual OK

Практическая реализация в Java/Spring

Локальные транзакции

@Service
public class OrderService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Transactional(isolation = Isolation.READ_COMMITTED)
    public Order createOrder(CreateOrderCommand cmd) {
        // Всё внутри одной транзакции
        Order order = new Order(cmd.getUserId(), cmd.getTotalAmount());
        orderRepository.save(order);
        
        // Если exception перед концом метода → откат
        // Если успешно завершился → коммит
        return order;
    }
}

Outbox + Inbox

// Отправитель
@Service
public class OrderCreationService {
    
    @Autowired
    private OrderRepository orderRepository;
    @Autowired
    private OutboxRepository outboxRepository;
    
    @Transactional
    public Order createOrder(CreateOrderCommand cmd) {
        Order order = Order.builder()
            .userId(cmd.getUserId())
            .status(OrderStatus.PENDING)
            .build();
        orderRepository.save(order);
        
        // В одной транзакции!
        OutboxEvent event = OutboxEvent.builder()
            .aggregateId(order.getId().toString())
            .eventType("OrderCreated")
            .eventData(objectMapper.writeValueAsString(order))
            .build();
        outboxRepository.save(event);
        
        return order;
    }
}

// Потребитель
@Service
public class PaymentService {
    
    @KafkaListener(topics = "order-events", groupId = "payment-service")
    @Transactional
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Проверка inbox
        if (inboxRepository.existsByEventId(event.getId())) {
            return;
        }
        
        // Обработка
        Payment payment = Payment.builder()
            .orderId(event.getOrderId())
            .amount(event.getAmount())
            .build();
        paymentRepository.save(payment);
        
        // В одной транзакции!
        InboxEvent inboxEvent = InboxEvent.builder()
            .eventId(event.getId())
            .eventType(event.getType())
            .build();
        inboxRepository.save(inboxEvent);
    }
}

Сравнение подходов

Таблица выбора паттерна

Альтернативные технологии

Заключение

Выбор подхода к консистентности зависит от:

1. Бизнес-требований: какие инварианты критичны
2. Технических ограничений: количество сервисов, требуемая latency
3. Операционных возможностей: умение поддерживать сложные паттерны

Общий принцип: начните с простого (synchronous вызовы или eventual consistency), добавляйте сложность только при необходимости.

Для большинства случаев: Saga + Outbox + Inbox комбинация решает 90% проблем консистентности в микросервисах.

Надёжность

Определение надёжности в контексте системного дизайна

Надёжность системы — это комплексная характеристика, включающая доступность, отказоустойчивость, долговечность данных и способность системы работать в условиях сбоев и перегрузок. Это ключевой аспект системного проектирования, влияющий на бизнес-метрики: потери транзакций в e-commerce, репутационные убытки и штрафы в финтехе и банковском секторе, нарушение SLA и контрактные обязательства перед клиентами.

Базовые метрики надёжности

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

Доступность — доля времени, в течение которой система способна обслуживать запросы. Формально:

[ \text{Availability} = \frac{\text{Uptime}}{\text{Uptime} + \text{Downtime}} \times 100% ]

Классификация доступности по "девяткам":

Каждая добавочная девятка экспоненциально увеличивает сложность архитектуры и инфраструктурные затраты. Для выбора целевого уровня доступности необходимо проанализировать business requirements:

• Критичные системы (финтех, здравоохранение, авиация): 99.99% и выше;
• Высокоприоритетные системы (социальные сети, электронная коммерция): 99.9%;
• Стандартные системы (большинство веб-приложений): 99%;
• Некритичные системы (аналитика, внутренние инструменты): 95-99%.

Надёжность (Reliability) и отказоустойчивость (Fault Tolerance)

Надёжность — вероятность того, что система успешно выполнит свою функцию без сбоев за определённый период. Это характеристика компонента или системы, измеряется через MTBF.

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

Различие на практике:

• Надёжная, но не отказоустойчивая система: сломалось одно место в монолите — упала вся система;
• Ненадёжная, но отказоустойчивая система: компоненты часто падают, но система продолжает работать через резервирование.

Архитектурно отказоустойчивость достигается через N+1 резервирование компонентов и изоляцию отказов.

Долговечность данных (Durability)

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

Реализуется через:

• Синхронная репликация: данные должны быть успешно записаны на несколько физических узлов перед подтверждением клиенту;
• Write-ahead logs (WAL): операция записывается в лог перед выполнением в основной структуре данных;
• Резервные копии: периодическое копирование полного состояния с возможностью восстановления;
• Разнесение данных: хранение копий в разных географических локациях и на разных типах носителей.

MTBF и MTTR

MTBF (Mean Time Between Failures) — среднее время между последовательными отказами компонента. Выражается в часах.

MTTR (Mean Time To Repair) — среднее время от момента обнаружения отказа до полного восстановления системы.

Доступность связана с этими метриками:

[ \text{Availability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} ]

Следовательно, есть два ортогональных пути повышения доступности:

1. Повысить MTBF: улучшить качество компонентов, снизить частоту отказов через redundancy и лучший инженеринг;
2. Снизить MTTR: внедрить автоматическое обнаружение отказов (health checks), быстрый failover, автоматическое восстановление.

Пример расчёта:

• MTBF каждого сервера: 2000 часов (примерно 1 сбой в 2.5 месяца);
• MTTR при автоматическом failover: 30 секунд;
• При N+2 резервировании: MTBF системы ≈ 667 часов, MTTR = 30 сек;
• Availability = 667 / (667 + 0.0083) ≈ 99.999% (5 девяток).

SLA, SLO, SLI

SLA (Service Level Agreement) — контрактное обязательство перед клиентом. Нарушение влечёт штрафы, скидки или возмещение.

SLO (Service Level Objective) — внутреннее целевое значение, жёстче SLA на 0.1–1%, обеспечивающее буфер для предупредительных действий.

SLI (Service Level Indicator) — конкретная измеримая метрика.

Типичные SLI для backend-систем:

Взаимосвязь при расчёте error budget:

Если SLO = 99.9% доступности, то monthly error budget = 0.1% от всех запросов за месяц. При 1M запросов в день это ~300 запросов в день, которые могут отказать.

Технологии и подходы для надёжности

Design for Failure — Проектирование для отказов

Основной принцип

Предположить, что всё может отказать. Это не пессимизм, а реальность production-систем на масштабе.

Идентификация Single Point of Failure (SPOF)

SPOF — компонент, отказ которого приводит к полной недоступности системы.

Примеры SPOF:

• Один load balancer перед всеми серверами приложения;
• Одна БД без репликации;
• Один узел в distributed cache без резервирования;
• Одна сеть между дата-центрами.

Метод выявления: нарисовать архитектуру и для каждого компонента задать вопрос: "Что если он упадёт?" Если ответ "система станет недоступна", это SPOF.

Правило проектирования: для компонентов, от которых критична доступность, обеспечить N+1 или N+2 резервирование, где N — количество отказов, которые система должна пережить.

Анализ точек отказа по слоям

Graceful Degradation — Контролируемая деградация

Концепция

Система деградирует функционально при частичных сбоях, но не падает полностью. Функционал приоритизируется, и критичные операции сохраняются за счёт отключения некритичных.

Стратегии деградации

1. Функциональная деградация: вернуть результат без опциональной функции вместо полного отказа.

   • Пример: при недоступности recommendation-сервиса показать товары без рекомендаций.

2. Качественная деградация: вернуть результат более низкого качества.

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

3. Асинхронная деградация: перевести долгую операцию в асинхронный режим вместо синхронного ответа.

   • Пример: при timeout на 1 секунду переключить запрос на обработку через очередь задач.

4. Кеширование результатов: использовать устаревшие данные при недоступности primary источника.

   • Пример: при отказе БД вернуть кешированный результат с меткой времени.

Проектирование деградации

Деградация требует предварительного проектирования: