System Design для Engineering Manager: основы и интервью в российском Big Tech

Формат System Design интервью для EM: ожидания, критерии, типовые задачи

System Design интервью на позицию Engineering Manager (EM) в российском Big Tech проверяет не только знание архитектурных паттернов, но и управленческое мышление: как вы принимаете решения в условиях неопределённости, как управляете рисками, как связываете технические компромиссы с целями продукта и возможностями команды.

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

Зачем EM дают System Design на интервью

Для EM в Big Tech архитектура важна как инструмент управления:

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

Принимать решения при неполных данных и фиксировать допущения

Выбирать технические компромиссы, объясняя их бизнесу и команде

Видеть риски эксплуатации: надёжность, стоимость, безопасность, процессы

Понимать, что можно делегировать сильным инженерам, а где нужен личный контроль

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

Типичный формат System Design интервью

Формат может отличаться по компаниям, но чаще всего это 45–60 минут с доской (виртуальной или реальной).

!Таймбоксинг интервью и ожидаемые этапы

Ниже практичный сценарий, который подходит почти всегда.

Уточнение задачи и требований

На старте интервьюер может сказать: «Спроектируйте сервис X». В этот момент ваша задача не бросаться рисовать базы данных, а превратить туманную формулировку в рабочую постановку.

Обычно уточняют:

Цель: что считаем успехом, какие ключевые пользовательские сценарии

Границы: что делаем сейчас, что явно не делаем

Пользователи: роли, география, мобильные или веб-клиенты

Ограничения: сроки, легаси, требования к данным, регуляторика

Результат этапа: краткий список функциональных требований и список нефункциональных требований.

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

Дальше вы предлагаете скелет решения: основные компоненты и потоки данных.

На этом этапе обычно достаточно:

Клиенты и внешние интеграции

API слой (шлюз, балансировщики)

Основные доменные сервисы

Хранилища и кэши на уровне блоков

Асинхронные части: очереди, стриминг, воркеры

Важна ясность: что с чем общается и зачем.

Оценка нагрузки и ключевых чисел

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

Что обычно считают:

DAU/MAU, RPS/QPS, пики

Средний размер сущностей (сообщение, событие, карточка)

Объём хранения в день и рост

Если цифр нет, вы:

Задаёте 1–2 уточняющих вопроса

Фиксируете допущения и проверяете, что интервьюер согласен

Глубокое погружение в 1–2 ключевых узла

В 60 минут невозможно глубоко раскрыть всё. Зрелый подход: выбрать самые рискованные или самые дорогие части и нырнуть туда.

Типовые направления deep dive:

Модель данных и индексы, горячие ключи

Шардирование, репликация, миграции

Кэширование и инвалидация

Очереди, ретраи, идемпотентность

Консистентность и конкуренция записей

Надёжность, эксплуатация и безопасность

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

Что стоит проговорить хотя бы верхнеуровнево:

Деградация и фолбэки, что происходит при отказах зависимостей

SLO/SLI, мониторинг, алерты, трассировка

Планирование ёмкости и стоимость

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

Полезный базовый источник по мышлению надёжности: Site Reliability Engineering (Google).

Итог: резюме, компромиссы, риски и план развития

Хорошее завершение:

Коротко повторить архитектуру

Назвать 2–3 главных компромисса и почему так

Выделить риски и что бы вы проверили в пилоте

Предложить план эволюции: MVP → рост нагрузки → новые требования

Что оценивают на System Design интервью EM

В инженерном интервью часто оценивают знание технологий. В EM интервью сильнее оценивают качество решений и коммуникации.

Ниже ориентир по критериям.

| Критерий | Что выглядит сильным ответом | Тревожные сигналы | |---|---|---| | Уточнение требований | Формулируете сценарии, границы, метрики, явно фиксируете допущения | Сразу рисуете БД и сервисы без постановки задачи | | Структура и коммуникация | Идёте по этапам, проговариваете варианты, сверяете понимание | Рваное изложение, много деталей без фокуса | | Архитектурное мышление | Декомпозиция на компоненты, понятные контракты, разумные зависимости | «Один сервис на всё», неясные потоки данных | | Масштабирование | Понимаете точки роста, где кэш/очереди/шардинг дают эффект | «Просто добавим серверов» без анализа узких мест | | Надёжность | Продумываете отказы, ретраи, идемпотентность, деградацию | Игнорируете сбои и эксплуатацию | | Данные и консистентность | Умеете говорить о вариантах консистентности и последствиях | Путаете модели, не замечаете гонки | | Стоимость и простота | Выбираете минимально сложное решение под требования | Микросервисы и сложные технологии ради моды | | EM-угол: управление рисками | Приоритизация, план итераций, зоны ответственности, эскалации | Только «технический рисунок», без управленческой части |

Если вы хотите структурированную шпаргалку по типовым темам и вопросам, полезен репозиторий The System Design Primer.

Чем System Design для EM отличается от System Design для Senior/Staff инженера

Разница не в том, что EM не должен знать детали, а в том, какие сигналы важнее.

Для EM обычно сильнее ценится:

Умение управлять неопределённостью: допущения, риски, план валидации

Выбор достаточного решения, а не максимально технологичного

Понимание организационных ограничений: команда, сроки, владение компонентами

Предложения по процессу внедрения: этапы, метрики, наблюдаемость, инциденты

При этом базовые технические темы всё равно должны быть на уровне уверенного лидера команды.

Типовые задачи для интервью в российском Big Tech

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

Лента рекомендаций или новостной фид

Мессенджер: чаты, доставка, статус прочтения

Поиск по каталогу с автодополнением

Сервис уведомлений: push/email/SMS с приоритетами

Антифрод и риск-скоринг по событиям

Трекер заказов/доставки: статусы, гео-события, ETA

Платформа A/B тестов и фича-флаги

Сбор логов/событий и аналитика near-real-time

Сервис биллинга/транзакций с неизменяемым журналом

Почти всегда в задаче есть скрытый «крючок»: большие пики, горячие ключи, требования по задержке, юридические ограничения на хранение данных или строгая корректность списаний.

Частые ошибки кандидатов на EM

Не фиксировать допущения и потом спорить на разных картинах мира

Уйти в детали реализации раньше, чем согласованы требования

Попытаться раскрыть всё, не выбрав 1–2 глубоких фокуса

Игнорировать эксплуатацию: алерты, деградации, ретраи, бэкапы

Выбрать технологически «круто», но управленчески невыполнимо для команды

Как готовиться к такому интервью

Тренируйте сценарий: требования → архитектура → нагрузка → deep dive → надёжность → итоги

Проводите репетиции с таймером на 45–60 минут

Учитесь объяснять компромиссы простыми словами: что выигрываем и что теряем

Подготовьте 5–7 типовых тем, в которые вы готовы нырнуть глубоко: кэш, очереди, шардинг, консистентность, идемпотентность, SLO

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

Сбор требований: бизнес-цели, нефункциональные требования, ограничения и SLO

На System Design интервью для Engineering Manager вы почти всегда выигрываете (или проигрываете) в первые 10–15 минут. Именно там вы превращаете формулировку «спроектируйте сервис X» в проверяемую постановку: зачем мы это делаем, что именно строим, какие есть ограничения и как измерим успех.

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

!Карта, как требования превращаются в SLO и затем в архитектуру

Почему EM начинают с бизнес-целей

Интервьюер проверяет не только технику, но и способность управлять неопределённостью:

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

Вы умеете сказать, что важнее сейчас: скорость выхода, стоимость, корректность, масштабируемость.

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

Для EM это особенно важно: вы отвечаете не за идеальную архитектуру, а за результат в реальной организации.

Термины без путаницы

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

Бизнес-цель — зачем продукту/компании это изменение (например, рост заказов, снижение отмен, увеличение LTV).

Функциональные требования — что система должна уметь (сценарии, операции, роли).

Нефункциональные требования — каким должно быть качество сервиса (задержка, доступность, безопасность, стоимость, масштабируемость).

Ограничения — неизменяемые условия (сроки, бюджет, легаси, регуляторика, доступные компетенции).

SLI (Service Level Indicator) — измеримый индикатор качества (например, доля успешных запросов).

SLO (Service Level Objective) — целевое значение SLI (например, 99.9% успешных запросов за 28 дней).

SLA (Service Level Agreement) — договор с последствиями (штрафы/компенсации). На интервью чаще достаточно SLO.

Официальная и очень практичная база по SLO: Service Level Objectives (The Site Reliability Workbook).

Структура сбора требований на интервью

Ниже — последовательность, которая хорошо укладывается в 5–15 минут и задаёт вам правильный темп.

Уточняем бизнес-цель и метрики успеха

Хорошие вопросы звучат как про продукт, а не про технологии.

Какой главный пользовательский сценарий и какая у него метрика успеха (конверсия, время до результата, доля успешных действий)?

Это новый продукт или замена/эволюция существующего?

Что критичнее: быстро запуститься или сразу обеспечить высокую надёжность?

Кто платит за ошибки: пользователи, бизнес, регулятор?

Результат: 1–2 бизнес-цели и 2–4 продуктовые метрики.

Фиксируем функциональные требования через сценарии

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

Роли и акторы (пользователь, курьер, оператор, партнёрская система).

Основные операции (создать, прочитать, обновить, отменить).

Критичный путь (что обязано работать всегда).

Что вне скоупа в рамках интервью.

Практика: после 3–5 вопросов сформулируйте вслух краткую постановку: «Правильно ли я понимаю, что мы проектируем X для Y, чтобы добиться Z, и в MVP делаем A/B/C, а D не делаем?».

Собираем нефункциональные требования как список компромиссов

Нефункциональные требования — это не чек-лист, который нужно «перечислить». Это выбор приоритетов. На интервью достаточно 5–7 пунктов, но каждый должен влиять на архитектуру.

Ключевые оси, по которым почти всегда есть компромисс:

Доступность (availability): что считаем простоем и кому он вреднее всего.

Задержка (latency): какой порог приемлем для пользователя и для внутренних интеграций.

Пропускная способность (throughput): средний и пиковый трафик.

Консистентность (consistency): можно ли показывать слегка устаревшие данные.

Надёжность обработки (durability): можно ли потерять события/сообщения.

Безопасность и приватность: какие данные чувствительные.

Стоимость: где дороже всего масштабироваться.

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

Явно спрашиваем про ограничения

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

Типовые ограничения:

Сроки и этапность: MVP за 3 месяца или «делаем год».

Команда и владение: сколько инженеров, какие компетенции, кто on-call.

Легаси: существующие БД/шины/протоколы, которые нельзя менять.

Регуляторика: хранение персональных данных, требования аудита.

Технологические запреты: нельзя использовать облако, нельзя Kafka, только on-prem.

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

Переводим NFR в SLI/SLO

SLO — это мост между «качество важно» и «как именно мы проверяем качество». В интервью обычно достаточно 2–3 SLO.

Алгоритм:

Выберите 1–2 пользовательских критичных сценария.

Для каждого определите SLI (как измеряем).

Задайте SLO (какой уровень считаем хорошим).

Уточните окно измерения (например, 7 или 28 дней).

Примеры типовых SLI:

Доля успешных запросов (HTTP 2xx/3xx) на конкретном endpoint.

p95/p99 задержки на критичном endpoint.

Доля доставленных уведомлений за заданное время.

Доля корректно обработанных событий без дублей.

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

База по мышлению надёжности и практикам SRE: Site Reliability Engineering (книга).

Как формулировать требования так, чтобы они вели к архитектуре

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

| Требование | Что это означает в дизайне | Типичные вопросы интервьюера | |---|---|---| | Высокая доступность | Репликация, отсутствие единой точки отказа, graceful degradation | Что будет при падении БД/очереди? | | Низкая задержка на чтение | Кэш, денормализация, предвычисления | Как будете инвалидировать кэш? | | Строгая корректность списаний | Транзакции, идемпотентность, журналирование, ограничение асинхронности | Как избегаете двойного списания? | | Пиковые нагрузки | Очереди, backpressure, лимиты, авто-масштабирование | Что в пике деградирует первым? | | Геораспределение | Multi-region, data locality, компромиссы консистентности | Какая модель консистентности допустима? | | Аудит и расследования | Неизменяемый лог, трассируемость, корреляционные идентификаторы | Как быстро найдёте причину инцидента? |

Шаблон результата: что вы должны произнести через 10 минут

Хороший выход из этапа требований — это короткая, структурированная сводка.

Цель: «Мы делаем X, чтобы улучшить Y; успех меряем метриками M1/M2».

Функциональность (MVP): 3–5 ключевых сценариев.

Нефункциональные приоритеты: 3–5 пунктов, ранжированных по важности.

Ограничения: сроки/легаси/регуляторика/команда.

SLO: 2–3 цели с понятными SLI.

Это не бюрократия. Это способ договориться с интервьюером о «правилах игры», чтобы дальше не спорить про разные картины мира.

Мини-кейс: сервис уведомлений (push/email/SMS)

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

Бизнес-цели

Увеличить конверсию ключевых действий (оплата, возврат, подтверждение).

Снизить количество обращений в поддержку за счёт информирования.

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

Отправка уведомлений по каналам push/email/SMS.

Шаблоны сообщений и персонализация по параметрам.

Приоритеты: критичные (безопасность, вход) и маркетинговые.

Планировщик: отправка «сейчас» и «в заданное время».

Трекинг статуса доставки (хотя бы на уровне принято к отправке и доставлено/не доставлено, если провайдер позволяет).

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

Критичные уведомления должны доходить быстро и надёжно.

Маркетинговые можно деградировать или задерживать в пик.

Нельзя отправлять дубликаты при ретраях.

Должны быть лимиты на пользователя/кампанию, чтобы не «положить» провайдера и не спамить.

Наблюдаемость: видно очередь, скорость обработки, ошибки провайдера.

Ограничения

Есть существующие провайдеры SMS/email, менять нельзя.

Команда маленькая, on-call несут 2 человека → важно простое и устойчивое решение.

Пример SLI/SLO

SLI: доля критичных уведомлений, доставленных в течение 30 секунд с момента приёма.

SLO: 99.9% за 28 дней для критичных.

SLI: p95 задержки API POST /send (принятие в обработку).

SLO: p95 < 200 мс за 28 дней.

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

Типичные ошибки на этапе требований

Сразу выбирать БД/очередь, не выяснив, что важнее: latency, correctness или time-to-market.

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

Называть SLO как красивые цифры без SLI и окна измерения.

Путать SLO и SLA, обещая то, что не сможете обеспечить.

Не фиксировать допущения: интервьюер думает про 1 млн DAU, вы — про 10 тыс.

Как EM может усилить ответ управленческими сигналами

На интервью полезно показать не только техническую сторону, но и управленческую зрелость.

Предложите этапность: MVP → стабилизация (наблюдаемость, алерты) → оптимизация стоимости.

Назовите основные риски и план валидации: нагрузочное тестирование, пилот на 1% трафика, канареечные релизы.

Сформулируйте, что будете измерять после запуска: продуктовые метрики и SLI.

Что дальше по курсу

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

Полезный справочник для дальнейшей практики формулировок и типовых тем: The System Design Primer.

Высокоуровневая архитектура: компоненты, границы сервисов, API и контракты

После этапа требований (бизнес-цели, NFR, ограничения, SLO) на System Design интервью наступает момент, когда вы должны быстро и уверенно нарисовать «скелет» системы: основные компоненты, их границы, ключевые потоки данных и контракты между ними.

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

!Пример «скелета» системы и потоков данных на доске

Что значит «высокоуровневая архитектура» на интервью

Высокоуровневая архитектура в контексте интервью — это:

Список главных компонентов и их роль.

Границы: что где живёт, кто чем владеет, где проходят контракты.

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

Пара ключевых архитектурных решений, вытекающих из требований.

При этом вы не уходите глубоко в выбор конкретной БД или тонкости индексов, пока не обозначили:

Входные интерфейсы (API/события).

Доменные сервисы.

Хранилища и кэш на уровне блоков.

Очереди/стриминг при необходимости.

Компоненты надёжности и эксплуатации: rate limiting, retry, idempotency, наблюдаемость.

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

Хороший способ не «поплыть» — связать каждый крупный компонент с конкретным требованием.

Пример связок:

Низкая задержка на чтение -> кэш, предвычисления, отдельный read-path.

Пиковые нагрузки -> очередь, воркеры, backpressure, лимиты.

Нельзя терять события -> персистентная очередь, подтверждения обработки, идемпотентность.

Жёсткие требования по приватности -> отдельный контур доступа, шифрование, аудит.

Маленькая команда и жёсткий срок -> меньше сервисов, проще контракты, управляемая эксплуатация.

В интервью полезно проговорить это явно: «Я рисую очередь, потому что у нас пики и мы хотим сгладить нагрузку на провайдера».

Типовые компоненты почти любой системы

Ниже — «кубики», из которых чаще всего собирается дизайн. Важно не перечислить всё, а выбрать релевантное требованиям.

Входной контур

Клиенты: мобильные, web, внутренние сервисы.

Edge: CDN, WAF, DDoS protection (если критично).

Балансировка и API Gateway: маршрутизация, аутентификация, лимиты.

Доменные сервисы

Service A: отвечает за конкретный домен и инварианты.

Service B: отвечает за другой домен и отдельный жизненный цикл.

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

Данные

Основное хранилище: транзакционные данные.

Кэш: ускоряет чтение, снижает нагрузку.

Поисковый индекс: если есть сложный поиск.

Хранилище событий/логов: если нужна аналитика или аудит.

Асинхронность

Очередь: выравнивает пики, изолирует от медленных зависимостей.

Воркеры: забирают задачи и выполняют.

Стриминг: если важен порядок, большие объёмы событий, много подписчиков.

Надёжность и эксплуатация

Rate limiting и квоты.

Retry/circuit breaker/таймауты.

Идемпотентность для критичных операций.

Наблюдаемость: метрики, логи, трассировка.

Границы сервисов: как декомпозировать систему

На интервью «границы сервисов» — одна из ключевых проверок зрелости. Частая ошибка кандидатов: дробить систему на микросервисы по наитию или, наоборот, делать «один сервис на всё» без объяснения.

Что такое граница сервиса простыми словами

Граница сервиса — это:

Набор данных и инвариантов, за которые сервис отвечает.

Контракт взаимодействия снаружи (API или события).

Независимость релиза и масштабирования (хотя бы частичная).

Полезная концепция для разговора — bounded context из DDD: один и тот же термин может означать разное в разных контекстах, и эти контексты лучше разделять. Практичная заметка: Bounded Context (Martin Fowler).

Признаки хорошей границы

Высокая связность внутри: сервис делает «одну работу».

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

Данные «живут там, где принимаются решения»: сервис владеет своими инвариантами.

Контракт относительно стабилен: изменения можно версионировать.

Типовые критерии для разбиения

Можно проговорить 3–5 критериев и выбрать те, что подходят задаче:

Разные SLO: критичный контур отдельно от некритичного.

Разная нагрузка: чтение и запись масштабируются по-разному.

Разный жизненный цикл: компонент меняется часто, другой почти статичен.

Разные зависимости: например, внешние провайдеры лучше изолировать.

Разные риски: операции со строгой корректностью отделить от «best effort».

Монолит, модульный монолит, микросервисы

Сильный EM-ответ — не «микросервисы всегда лучше», а выбор по ограничениям.

Монолит: быстрее MVP, проще отладка, ниже накладные расходы, но сложнее независимые релизы и масштабирование.

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

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

В российских Big Tech обычно ценят, когда кандидат явно называет стоимость микросервисов: on-call, наблюдаемость, CI/CD, управление схемами и версиями.

API и контракты: что именно вы обещаете клиентам и соседним сервисам

Контракт — это договорённость, благодаря которой системы могут развиваться независимо.

Контракт включает:

Формат данных.

Семантику операций: что означает успех и ошибка.

Требования к идемпотентности.

Версионирование и обратную совместимость.

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

Синхронный API: HTTP и gRPC

На интервью достаточно сказать, когда какой стиль уместен:

HTTP API: внешний контур, интеграции, человекоориентированная отладка.

gRPC: внутренние сервисы, строгая схема, эффективность, много вызовов.

Реальные спецификации, на которые можно опереться:

OpenAPI Specification

gRPC Introduction

Protocol Buffers Overview

Контракты в HTTP: статусы, ошибки, идемпотентность

Если вы проектируете HTTP API, важно не только назвать endpoints, но и договориться о поведении.

Минимальный набор правил, который выглядит зрело:

Таймауты на клиентах и сервисах, чтобы не копить «висящие» запросы.

Единый формат ошибки: код, сообщение, correlation id.

Идемпотентность на операциях создания или списания, если возможны ретраи.

Идемпотентность простыми словами: повтор одного и того же запроса не должен приводить к повторному эффекту.

Практический пример подхода через Idempotency-Key: Stripe: Idempotent requests.

Про семантику HTTP статусов полезно помнить на уровне принципов: RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content.

События и асинхронные контракты

Асинхронные контракты обычно выражаются через:

События домена: OrderPaid, MessageSent.

Команды/задачи: SendNotification.

Важно проговорить:

Гарантии доставки: at-most-once, at-least-once.

Что делаем с дублями: идемпотентные обработчики.

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

Схема события: версионирование, обязательные/опциональные поля.

На интервью вы не обязаны называть конкретный брокер, но обязаны обозначить последствия: при at-least-once дубли неизбежны, значит в обработке нужны ключи идемпотентности.

Версионирование контрактов и обратная совместимость

В Big Tech интервьюер часто проверяет, понимаете ли вы, как система живёт в реальности: сервисы релизятся не одновременно.

Практичные правила:

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

В JSON: новые поля должны быть опциональными для старых клиентов.

В Protobuf: нельзя переиспользовать удалённые номера полей.

Стратегии версионирования HTTP API:

Версия в пути: /v1/....

Версия в заголовке: Accept: application/vnd.company.v1+json.

Главное на интервью — не выбрать «единственно правильный» способ, а показать контроль изменений и миграций.

Внутренние контракты: ownership, SLO и эксплуатация

Для EM «контракты» — это ещё и организационные договорённости:

Кто владеет сервисом и данными.

Кто несёт on-call и принимает инциденты.

Какие SLO у сервиса и какие зависимости критичны.

Какие лимиты вы ставите клиентам, чтобы защитить систему.

Хороший высокоуровневый дизайн обычно содержит явные «предохранители»:

Rate limits на входе.

Очередь для сглаживания пиков.

Graceful degradation: что отключаем первым при перегрузке.

Это напрямую связано с тем, что обсуждалось в статье про SLO: сначала вы определяете критический путь и цели качества, а затем проектируете контуры, которые эти цели защищают.

Мини-кейс: высокоуровневый дизайн сервиса уведомлений

Возьмём пример из прошлой статьи, но теперь сделаем фокус на архитектуре, границах и контрактах.

Компоненты

Notification API: принимает запросы на отправку.

Auth: проверяет права вызывающего.

Rate Limiter: применяет квоты по клиенту/кампании.

Queue: буферизует задания на отправку.

Sender Workers: отправляют в провайдеров и обновляют статусы.

Template Service: хранит шаблоны и рендерит текст.

Status Store: хранит состояние уведомления.

Observability: метрики, логи, трассировка.

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

Notification API отвечает за валидность запроса, идемпотентность на приёме и постановку в очередь.

Sender Workers отвечают за ретраи, обработку ошибок провайдеров и обновление статусов.

Template Service изолирует работу с шаблонами, чтобы отправка не зависела от деталей рендеринга.

Пример синхронного контракта

POST /notifications:send

В ответе: notification_id, статус accepted.

Идемпотентность: клиент передаёт Idempotency-Key.

Смысл: API быстро подтверждает приём, а реальная отправка происходит асинхронно.

Пример асинхронного контракта

Команда в очередь: SendNotification.

Поля: notification_id, channel, recipient, payload, priority, idempotency_key.

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

Как этот этап «продаётся» на интервью

Чтобы выглядеть структурно и по-EM-ски, завершите high-level блок коротким резюме:

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

Какие контракты между компонентами и какие у них гарантии.

Какие 2–3 главных риска и куда вы пойдёте в deep dive.

Примеры deep dive после high-level:

Идемпотентность и обработка дублей.

Стратегия ретраев и dead-letter очередь.

Модель статусов и консистентность.

Наблюдаемость и алерты по SLO.

Частые ошибки кандидатов

Рисовать много сервисов без причины и без ownership.

Смешивать критичный и некритичный трафик в одном контуре без деградации.

Забывать про контракты: форматы ошибок, версии, идемпотентность.

Делать синхронным всё, что может быть асинхронным, и получать цепочки таймаутов.

Не обозначать «предохранители»: лимиты, очереди, таймауты.

Связь с вашим опытом QA и тимлида

Ваш опыт можно превратить в сильные сигналы на интервью:

Контракты как тестируемый артефакт: схемы, негативные кейсы, совместимость.

Контрактное тестирование для API и событий.

План эволюции: MVP с минимальным числом компонентов, затем выделение сервисов по мере роста.

Если хочется упомянуть конкретный инструмент как пример (не обязательно на интервью), у contract testing есть известная практика: Pact Documentation.

Что дальше по курсу

Теперь у вас есть «скелет» системы: компоненты, границы, API и контракты. Следующий логичный шаг в подготовке к интервью — научиться подкреплять этот скелет числами и узкими местами: оценка нагрузки, пики, объёмы данных и выбор стратегий масштабирования.

Для общего кругозора по темам интервью полезен справочник: The System Design Primer.

Данные и хранение: моделирование, транзакции, консистентность, выбор БД

После требований (бизнес-цели, NFR, SLO) и высокоуровневой архитектуры (компоненты, границы сервисов, контракты) наступает этап, который почти всегда определяет судьбу системы: как именно вы храните данные и какие гарантии даёте продукту и соседним сервисам.

На System Design интервью для Engineering Manager это проверяют не как экзамен по конкретным СУБД, а как способность:

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

Объяснять последствия: стоимость, сложность, риски эксплуатации

Проектировать изменения: миграции, обратную совместимость схем, план эволюции

!Как связать транзакционную запись, публикацию событий и быстрые чтения без распределённых транзакций

Что интервьюер хочет услышать от EM про данные

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

Где нужна транзакционность и какой уровень изоляции достаточен

Где вы сознательно выбираете eventual consistency и как это влияет на UX и SLO

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

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

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

Начинайте не с таблиц, а с инвариантов

Инвариант — правило, которое нельзя нарушать даже при сбоях, ретраях и параллельных запросах.

Типовые инварианты, которые меняют дизайн:

Нельзя создать два активных заказа с одним и тем же внешним идентификатором

Баланс пользователя не может стать отрицательным

Одно уведомление нельзя отправить дважды при повторе запроса

Практический приём для интервью:

Назовите 2–3 инварианта

Скажите, кто за них отвечает: БД, сервис, или оба

Сущности и связи: минимум, который стоит проговорить

Сущность — объект предметной области (заказ, сообщение, уведомление)

Идентификатор — уникальный ключ (обычно суррогатный id, иногда бизнес-ключ)

Связи — 1:1, 1:N, N:M

Частая ошибка: смешать домены в одну модель и потом «лечить» это микросервисами. Если из прошлой статьи вы выделили границы сервисов, то на уровне данных правило простое:

Сервис владеет своими данными и отвечает за их инварианты

Другие сервисы получают данные через API или события, а не через прямой доступ к базе

Нормализация и денормализация

Нормализация уменьшает дублирование и упрощает поддержание корректности, но может удорожать чтения (join) и усложнять масштабирование

Денормализация ускоряет чтения и уменьшает число запросов, но добавляет риск рассинхронизации и усложняет обновления

Хорошая формулировка на интервью:

«В write-модели держим нормализованные данные для корректности, а для быстрых чтений строим проекции и кэш»

Индексы и «горячие ключи»

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

Типовые ловушки:

Индекс есть, но запрос не использует его из-за типа/функции/неподходящего порядка полей

Горячий ключ: один идентификатор генерирует непропорционально много операций (например, популярный чат или один «глобальный счётчик»)

Для EM полезно проговаривать не детали, а подход:

«Самые горячие запросы фиксируем и проверяем EXPLAIN, а горячие ключи режем шардированием по правильному ключу или переразложением данных»

Транзакции: что гарантирует ACID и где это реально нужно

Транзакция — способ атомарно применить набор изменений. В классических реляционных СУБД вы опираетесь на ACID:

Atomicity — либо всё, либо ничего

Consistency — сохранение инвариантов (в рамках ограничений/проверок)

Isolation — параллельные транзакции не ломают логику друг друга

Durability — после коммита данные переживают сбой

База для терминов и поведения транзакций в практике: Документация PostgreSQL.

Уровни изоляции: как говорить на интервью без углубления в теорию

Изоляция определяет, какие эффекты параллельности допустимы. Самые прикладные уровни:

Read committed: чтение видит только закоммиченные данные, но повторное чтение может дать другой результат

Repeatable read: в рамках транзакции чтения стабильнее, но возможны конфликты на записи

Serializable: поведение как будто транзакции выполнялись последовательно, но цена — блокировки/аборты

На интервью выигрывает связка: инвариант → изоляция → цена.

Например:

«Для списаний денег/изменения остатков нужен уровень, при котором мы не допускаем гонок, и мы готовы платить ретраями транзакций»

Справочник по изоляции в PostgreSQL: Transaction Isolation.

Где транзакции обязательны

Перевод состояния в конечном автомате, где нельзя перескочить этапы (например, created -> paid -> shipped)

Инкремент/декремент остатков и балансов

Уникальность бизнес-ключей (через UNIQUE и корректное поведение при конфликте)

Где транзакции вредны или избыточны

Длинные транзакции, включающие внешние вызовы (платёжный провайдер, SMS-шлюз)

Сценарии, где допустима eventual consistency (обновление поискового индекса, счётчики просмотров)

Консистентность: что вы обещаете пользователю и сервисам

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

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

Strong consistency: после успешной записи последующее чтение видит новое состояние

Eventual consistency: после записи система со временем сходится к новому состоянию, но некоторое время могут читаться старые данные

Важно проговаривать последствия:

При eventual consistency нужно проектировать UX: «статус обновится через несколько секунд», «показываем метку “обновляется”», «даем страницу статуса операции»

Если вы упоминаете CAP как рамку, делайте это прикладно: при сетевых проблемах распределённая система часто выбирает между доступностью и строгой консистентностью. Справочная статья: CAP theorem.

At-least-once доставка и дубли: неизбежный разговор

Во многих архитектурах (очереди, брокеры, ретраи) вы получаете доставку at-least-once, то есть возможны дубли.

Два базовых инструмента, которые выглядят зрело:

Идемпотентность обработчиков (одну и ту же команду можно применить повторно без двойного эффекта)

Дедупликация (хранение обработанных message_id/event_id с TTL)

Связка с предыдущей статьёй про контракты:

Идемпотентность — часть контракта: через Idempotency-Key в синхронном API или через event_id в событиях

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

Типовой «крючок» интервью: «Мы записали в БД, но сервис упал до публикации события» или наоборот.

Решение, которое часто ждут: Transactional Outbox.

Суть:

В одной транзакции с бизнес-записью вы добавляете запись в таблицу outbox

Отдельный процесс читает outbox и публикует события в брокер

После успешной публикации помечает запись как отправленную

Паттерн: Transactional outbox.

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

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

Нужна идемпотентность на стороне потребителей

Распределённые транзакции и саги

Когда одна бизнес-операция затрагивает несколько сервисов, «одна транзакция на всё» обычно неприменима.

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

Сказать, что распределённые транзакции дорогие и хрупкие в эксплуатации

Предложить сагу как оркестрацию или хореографию шагов

Обозначить компенсирующие действия и точки наблюдаемости

Паттерн: Saga.

Выбор типа хранилища: практическая матрица

Правильный ответ на интервью редко звучит как «всегда PostgreSQL». Он звучит как «под такие операции, объём и SLO достаточно X, а для Y строим отдельный контур».

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

Реляционные OLTP (PostgreSQL, MySQL)

Key-value (Redis как кэш и иногда как основное хранилище для простых кейсов)

Документные (MongoDB)

Wide-column (Cassandra)

Поисковые индексы (Elasticsearch/OpenSearch)

Колоночные аналитические (ClickHouse)

Объектное хранилище (для файлов и больших блобов)

Документация по распространённым системам:

Документация PostgreSQL

MySQL Reference Manual

Redis Documentation

MongoDB Manual

Apache Cassandra Documentation

ClickHouse Documentation

Elasticsearch Reference

Таблица выбора

| Задача | Что обычно выбирают | Почему | Типовые риски | |---|---|---|---| | Транзакционные операции, инварианты, сложные запросы | Реляционная БД | Транзакции, ограничения, богатые запросы | Масштабирование записи, миграции, конкуренция | | Очень быстрые чтения, защита от пиков | Кэш (Redis) | Миллисекунды, снижение нагрузки | Инвалидация, согласованность, eviction | | Гибкая схема документов, быстрый старт | Документная БД | Удобно хранить вложенные структуры | Сложные join, контроль инвариантов | | Огромные объёмы событий и высокая запись | Wide-column | Горизонтальное масштабирование | Модель запросов «сначала», сложнее изменения | | Полнотекстовый поиск, фильтры, ранжирование | Поисковый индекс | Инвертированные индексы, релевантность | Eventual consistency, стоимость памяти | | Аналитика, агрегации по большим данным | Колоночная БД | Быстрые сканы и агрегации | Не для OLTP, другие подходы к схемам |

Один сервис — несколько хранилищ

Для зрелого дизайна нормально:

OLTP база как источник истины

Кэш для ускорения чтений

Поисковый индекс для поиска

Колоночная база для аналитики

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

Шардирование, репликация, партиционирование: как не перепутать

Три термина, которые на интервью часто смешивают:

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

Шардирование — разбиение данных по узлам для масштабирования записи и объёма

Партиционирование — разбиение внутри одной логической таблицы по диапазону/ключу (часто по времени)

Что важно для EM:

На репликации чтения растут проще, но запись остаётся узким местом

Шардирование требует выбора ключа и стратегии ребалансировки

Партиционирование часто решает эксплуатационные задачи: TTL, быстрые удаления, управление размером

Эволюция схемы и миграции: управленческая часть, которую любят на интервью

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

Зрелая стратегия изменений:

Backwards compatible изменение схемы (добавили новое поле, колонку, таблицу)

Двойная запись или «старый+новый» путь чтения на время миграции

Фоновая миграция данных (backfill)

Переключение чтения на новый путь

Удаление старого после окна безопасности

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

Мини-кейс: статусы уведомлений и консистентность

Продолжим пример сервиса уведомлений из предыдущих статей.

Частый вопрос: где хранить статус и как показывать его клиенту.

Практичный вариант:

В транзакционной БД хранить запись notification со статусом accepted/sent/failed

Отправку делать асинхронно через очередь

Обновление статуса делать воркером

Что проговорить про консистентность:

Сразу после POST /notifications:send статус будет accepted, а sent появится позже

Это соответствует контракту и SLO: API отвечает быстро, доставка контролируется отдельно

Для критичных уведомлений можно выделить отдельную очередь и отдельные воркеры, чтобы выполнять более строгий SLO

Как усилить ответ с вашим бэкграундом QA и тимлида

Говорите об инвариантах как о проверяемых свойствах: уникальность, конечные автоматы статусов, идемпотентность

Подчёркивайте контрактность данных: схема, версии событий, обратная совместимость

Добавляйте эксплуатационные «предохранители»: миграции без даунтайма, бэкапы, план отката, метрики по очередям и ошибкам

Что дальше

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

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

Масштабирование и производительность: кэширование, очереди, шардирование, rate limiting

После того как вы:

собрали требования и SLO

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

определились с данными, транзакциями и консистентностью

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

Для Engineering Manager этот блок особенно важен, потому что он показывает управленческую зрелость:

вы не «оптимизируете в вакууме», а улучшаете конкретные SLI

вы контролируете риск инцидентов и стоимость эксплуатации

вы умеете выбирать достаточные меры под ограничения команды

!Общая карта, где в архитектуре обычно применяются кэш, очереди, шардирование и лимиты

Откуда берутся «цифры»: RPS, пики и узкие места

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

Базовая формула, которую можно назвать вслух:

-

Где:

— количество запросов

— время в секундах

— среднее число запросов в секунду

Практически важнее не формула, а вопрос: какой у нас пик и что считается критичным путём по SLO.

Типовые причины «внезапных» пиков:

сезонность и маркетинговые кампании

релизы мобильного клиента

повторные запросы из-за таймаутов и ретраев

проблемы зависимости, из-за которых растёт очередь запросов

Кэширование

Кэш — это инструмент для снижения задержек и нагрузки на более дорогие компоненты (БД, внешние сервисы). В интервью важно проговорить три вещи:

что именно кэшируем

где кэш живёт

как управляем устареванием и инвалидацией

Базовая документация: Документация Redis.

Где кэш ставят в архитектуре

Клиентский кэш

- Например, HTTP caching, локальное хранение на мобильном клиенте. - Снижает нагрузку, но сложнее контролировать актуальность.

Edge-кэш

- CDN для статики и иногда для публичных API. - Хорошо для контента и редко меняющихся ответов.

Серверный кэш рядом с сервисом

- Чаще всего Redis. - Даёт лучший контроль и наблюдаемость.

Кэш внутри процесса

- Быстро, но риск несогласованности при нескольких инстансах.

Что кэшировать: типовые цели

Read-heavy данные с терпимой задержкой актуализации

Результаты дорогих вычислений

Справочники и конфигурации

Рендеренные шаблоны (например, для уведомлений)

Отсылка к предыдущей статье про данные: источник истины обычно остаётся в OLTP-хранилище, а кэш — это ускоритель чтений, который может быть eventually consistent.

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

Cache-aside (lazy loading)

- Приложение сначала смотрит в кэш, при промахе читает из БД и кладёт в кэш. - Плюсы: просто внедрять. - Минусы: нужен контроль инвалидации и «шторм» при массовых промахах.

Read-through

- Кэш сам ходит в БД при промахе. - Плюсы: выносит логику заполнения. - Минусы: сложнее, чаще платформенное решение.

Write-through

- Сначала пишем в кэш, кэш синхронно пишет в БД. - Плюсы: кэш всегда тёплый. - Минусы: кэш становится частью критичного пути по доступности.

Write-behind (write-back)

- Пишем в кэш, в БД — асинхронно. - Плюсы: быстрые записи. - Минусы: риск потери данных и сложности консистентности; на интервью это нужно отдельно обосновывать.

Инвалидация и TTL: самый частый «крючок» интервью

Кэширование редко «сложно» само по себе. Сложно — поддерживать предсказуемую актуальность.

Типовые подходы:

TTL (время жизни ключа)

- Простая модель: данные могут быть устаревшими максимум на TTL. - Хорошо для справочников и нестрогих данных.

Явная инвалидация по событию

- При изменении данных публикуется событие, по нему удаляется/обновляется кэш. - Хорошо, когда нужна более свежая выдача.

Версионирование ключей

- Ключ включает версию сущности, при обновлении меняется версия. - Полезно, когда явную инвалидацию делать сложно.

EM-сигнал: назвать риск «thundering herd» — когда истёк TTL у популярного ключа, и много инстансов одновременно идут в БД. Типовые меры:

добавлять «джиттер» к TTL

использовать блокировку на заполнение (single flight)

делать stale-while-revalidate: отдаём слегка устаревшее и обновляем в фоне

Очереди и асинхронная обработка

Очередь — это инструмент, который:

сглаживает пики (буферизует нагрузку)

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

упрощает ретраи и повышает надёжность обработки

Важно: очередь не «ускоряет» обработку сама по себе. Она делает систему более управляемой при перегрузке.

Реальные источники:

Документация Apache Kafka

Документация RabbitMQ

Очередь как часть SLO

Связь с темой SLO из прошлых статей:

API на критичном пути может отвечать быстро с семантикой accepted

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

SLO на обработку формулируется как «доля задач, обработанных за N секунд»

Гарантии доставки и их последствия

At-most-once

- Дубликатов почти нет, но возможна потеря. - Подходит для некритичных событий.

At-least-once

- Потеря минимизируется, но дубликаты возможны. - Требует идемпотентных обработчиков и/или дедупликации.

Отсылка к статье про данные и консистентность: at-least-once почти всегда приводит к разговору про идемпотентность, ключи дедупликации и дизайн состояния.

Ретраи, backoff и dead-letter очередь

Зрелый ответ на интервью включает политику ошибок:

Retry с экспоненциальной задержкой

- Снижает давление на зависимость.

Circuit breaker и таймауты

- Не даём очереди раздуваться бесконечно из-за зависшего провайдера.

Dead-letter queue (DLQ)

- Сообщения, которые не удалось обработать после лимита попыток. - Нужен процесс разбора: алерт, ручная обработка, автопочинка.

EM-сигнал: проговорить ownership DLQ — кто несёт ответственность и какой SLA у разбора.

Backpressure: что делаем при перегрузке

Если вход превышает пропускную способность воркеров, очередь растёт. Вам нужен план:

лимиты на входе (rate limiting)

динамическое масштабирование воркеров

приоритизация (критичное отдельно от некритичного)

деградация: что сбрасываем/задерживаем первым

Шардирование и работа с «горячими» данными

Шардирование — разбиение данных по нескольким узлам, чтобы масштабировать объём и запись. Часто его путают с репликацией:

репликация обычно помогает чтениям и отказоустойчивости

шардирование — про масштаб записи и общий объём

!Почему выбор shard key определяет равномерность нагрузки и риск «горячих» шардов

Когда шардирование действительно нужно

Типовые сигналы:

запись упёрлась в один инстанс БД, вертикально расти некуда

объём данных приближается к эксплуатационному пределу (бэкапы, вакуум, время восстановления)

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

EM-сигнал: шардирование — дорогая мера по сложности. На интервью хорошо звучит позиция: сначала репликация/партиционирование/оптимизация запросов, потом шардирование.

Выбор shard key

Правило: выбирайте ключ, который:

присутствует почти во всех запросах

обеспечивает равномерное распределение

минимизирует кросс-шардовые операции

Типовая ловушка: «красивый» ключ, который создаёт перекос.

Примеры:

сообщения в чате: шардирование по chat_id часто лучше, чем по user_id

заказы: иногда по user_id, иногда по order_id, в зависимости от запросов

события: часто по (tenant_id, time_bucket)

Ребалансировка и миграции шардов

Шардирование почти всегда приводит к вопросу: что будет, когда шардов станет больше.

Практичные варианты, которые можно проговорить:

Consistent hashing

- Уменьшает объём перемещаемых данных при добавлении узлов. - Чаще встречается в распределённых KV/кэшах.

Диапазонное шардирование

- Прозрачно для запросов, но сложнее ребалансировать.

Каталог маршрутизации (shard map)

- Отдельный слой/таблица, которая говорит, где живёт ключ. - Требует высокой надёжности этого каталога.

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

Партиционирование по времени как «дешёвый выигрыш»

Отсылка к статье про данные: если данные естественно временные (события, логи, статусы), партиционирование по времени часто даёт большой эффект:

быстрее удаление старых данных

проще TTL и управление объёмом

меньше индексный мусор

Источник: Документация PostgreSQL про партиционирование.

Rate limiting и защита системы

Rate limiting — это не про «безопасность ради безопасности». Это про управляемость SLO и предотвращение самоуничтожения системы при пиках и ошибках клиентов.

В интервью важно назвать:

где ставим лимиты (edge, gateway, сервис)

по какому ключу лимитируем (user, token, IP, tenant, client_id)

что делаем при превышении (ошибка, деградация, постановка в очередь)

Базовые справочные источники:

Token bucket

Leaky bucket

Типовые политики лимитов

Пер-пользователь

- Защищает от злоупотреблений.

Пер-клиент или пер-интеграцию

- Особенно важно для внутренних сервисов и партнёров.

Пер-кампанию или пер-тенант

- Защищает от «одного большого клиента», который съедает всё.

Глобальный лимит на компонент

- Предохранитель для защиты БД/провайдера.

Что возвращаем клиенту

Хороший контракт обычно включает:

понятный код ошибки (например, HTTP 429)

рекомендации по ретраю (например, через заголовок Retry-After)

корреляционный идентификатор для расследования

EM-сигнал: договориться о том, какие клиенты имеют приоритет (например, критичный внутренний контур) и как это оформлено организационно.

Как выбрать технику: кэш, очередь, шардирование, лимиты

Ниже — упрощённая матрица, которую удобно держать в голове на интервью.

| Проблема | Часто помогает | Что выигрываем | Что усложняем | Типичный вопрос интервьюера | |---|---|---|---|---| | Высокая задержка чтения, дорогие запросы | Кэш | p95/p99 latency, нагрузка на БД | Инвалидация, консистентность | Что будет с устаревшими данными? | | Пики нагрузки и медленные зависимости | Очередь | Сглаживание пиков, изоляция критичного пути | Ретраи, DLQ, наблюдаемость очередей | Как гарантируете обработку без дублей? | | Запись/объём упёрлись в одну БД | Шардирование/партиционирование | Масштаб объёма и записи | Миграции, кросс-шардовые запросы | Что с транзакциями и джойнами? | | Перегрузка, злоупотребления, каскадные отказы | Rate limiting | Защита SLO и зависимостей | Политики, fairness, исключения | Кого лимитируем и почему? |

Мини-кейс: сервис уведомлений под пики

Свяжем всё с примером из предыдущих статей.

Требования:

критичные уведомления должны доходить быстро

маркетинговые можно задерживать

провайдеры имеют ограничения по RPS

нельзя дублировать отправки при ретраях

Высокоуровневое решение:

Rate limiting на входе

- лимит по client_id и типу уведомлений - защита от «взрыва» маркетинга

Две очереди или приоритеты

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

Идемпотентность

- на приёме через Idempotency-Key - у воркеров — дедупликация по notification_id

Кэширование шаблонов

- шаблоны и справочники каналов кэшируются с TTL

Рост данных

- статусы уведомлений партиционируются по времени - архивирование старых записей

Сильное завершение на интервью: перечислить 2–3 ключевых риска и как вы их проверите:

нагрузочное тестирование на пики

хаос-тесты на недоступность провайдера

алерты на рост очередей и долю DLQ

Что обычно проверяют у EM в этом блоке

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

понимание, что кэш и очередь меняют консистентность и требуют контрактов

зрелость в эксплуатации: метрики, алерты, DLQ, деградация

понимание стоимости: шардирование и микросервисы повышают нагрузку на on-call

Что дальше по курсу

Теперь у вас есть набор практических рычагов, которые превращают «скелет архитектуры» в систему, выдерживающую рост и пики.

Следующий логичный шаг в подготовке к интервью — связать всё в единый рассказ про надёжность и эксплуатацию: наблюдаемость, SLI/SLO на компоненты, стратегии деградации и работа с инцидентами.

Надежность и эксплуатация: отказоустойчивость, наблюдаемость, инциденты, DR

После требований и SLO, высокоуровневой архитектуры, данных и масштабирования наступает блок, который для Engineering Manager в Big Tech часто решающий: как система живёт в продакшене. На System Design интервью это проявляется в вопросах:

Что произойдёт при падении зависимости или перегрузке?

Как вы поймёте, что пользователю стало плохо, и как быстро?

Кто и как действует при инциденте?

Что будет при потере датацентра/региона?

В этой статье мы соберём практичную рамку: отказоустойчивость, наблюдаемость, управление инцидентами и disaster recovery (DR). Цель не в том, чтобы перечислить инструменты, а в том, чтобы показать причинно-следственную связь: SLO → риски → механизмы защиты → операционные процессы.

!Слои, на которых обычно обеспечивают надёжность и где включается наблюдаемость

Как говорить о надёжности на интервью EM

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

Из статьи про требования: у вас есть критичные пользовательские сценарии и 2–3 SLO.

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

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

Из статьи про масштабирование: у вас есть кэш, очереди, лимиты и понимание пиков.

Теперь вы добавляете главное EM-измерение: операционные гарантии и управляемость.

Практичная формула разговора:

Назвать 1–2 критичных SLI.

Назвать основные классы отказов.

Показать механизмы защиты критичного пути.

Объяснить, как система наблюдается и как команда реагирует.

Закрыть DR: RPO/RTO и стратегия восстановления.

Базовый источник по мышлению SRE, полезный для формулировок на интервью: Site Reliability Engineering (Google).

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

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

Модель отказов, которую стоит проговорить

Типовые классы проблем в продакшене:

Отказ зависимости: БД недоступна, брокер не принимает, внешний провайдер отвечает ошибками.

Деградация зависимости: время ответа растёт, появляются таймауты.

Перегрузка: входной поток превышает пропускную способность, растут очереди, начинают срабатывать ретраи.

Частичная потеря данных: сообщение обработано, но подтверждение потерялось, появляются дубли.

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

EM-сигнал: вы не обещаете, что отказов не будет, вы показываете, что они контролируемы.

Таймауты, ретраи и почему они опасны без ограничений

Три правила, которые звучат зрело и применимы почти в любой задаче:

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

Ретраи должны быть ограничены и иметь backoff, иначе вы создаёте ретрай-шторм.

Ретраи должны сочетаться с идемпотентностью, иначе возможен двойной эффект.

Полезная формулировка на интервью:

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

Circuit breaker, bulkhead и graceful degradation

Когда зависимость деградирует, лучше быстро перестать её дергать, чем ждать таймауты и уронить весь сервис.

Circuit breaker прекращает вызовы в зависимость при ухудшении и даёт ей восстановиться.

Bulkhead изолирует ресурсы: например, отдельные пулы потоков/лимиты для разных типов запросов, чтобы некритичный трафик не «съел» критичный.

Graceful degradation определяет, что именно сервис отключает первым.

Важно: деградация должна быть связана с приоритетами из требований.

Пример:

Критичные уведомления идут по отдельному контуру (очередь/воркеры/лимиты) и защищены сильнее.

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

Идемпотентность как инструмент надёжности

Если вы используете очереди и ретраи (а вы почти всегда будете их использовать), то гарантия доставки часто становится at-least-once, а значит возможны дубли.

Практичный контракт:

В синхронном API: Idempotency-Key на операции создания/отправки.

В асинхронных сообщениях: уникальный event_id или command_id.

Это связывает статью про контракты и статью про данные: дедупликация и идемпотентные обработчики защищают бизнес-инварианты.

Single point of failure и минимум по High Availability

На интервью достаточно выявить SPOF и дать базовые меры:

Несколько инстансов stateless-сервиса за балансировщиком.

Health checks и автоматическое исключение больных инстансов.

Репликация БД и план failover.

Для очередей: персистентность и настройка подтверждений.

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

Где:

это время, когда сервис успешно обслуживает запросы по вашему SLI.

это всё время наблюдения (например, 28 дней).

В интервью важно не считать цифры до третьего знака, а показать причинность: чем больше SPOF в критичном пути, тем сложнее держать высокий Availability.

Наблюдаемость: метрики, логи, трейсы и связь с SLO

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

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

Три столпа наблюдаемости

Метрики: числовые ряды во времени (RPS, ошибки, задержка, размер очереди).

Логи: события с контекстом (кто, что сделал, какая ошибка).

Трейсы: распределённые трассировки запросов по сервисам (где потеряли время).

EM-сигнал: вы строите наблюдаемость вокруг критичных пользовательских сценариев и SLO, а не вокруг количества графиков.

Golden signals и что реально мониторить

Часто достаточно базовых четырёх сигналов:

Latency: p95/p99 задержки критичных endpoint.

Traffic: RPS/QPS по ключевым операциям.

Errors: доля ошибок и их типы.

Saturation: использование ресурсов и очередей (CPU, pool, queue lag).

Источник, который часто цитируют в SRE-культуре: Monitoring Distributed Systems (Google SRE).

SLI, алерты и борьба с шумом

Типовая ошибка на интервью: сказать у нас будут метрики и не объяснить, что именно будет алертить и почему.

Практичный подход:

Алерты строятся вокруг нарушения SLO или вокруг угрозы его нарушения.

Алерт должен быть действиямым: на него есть понятный первый шаг.

Для системы алертов важен контроль шума, иначе on-call перестаёт доверять сигналам.

Полезная рамка про SLO и алертинг: Service Level Objectives (Google SRE Workbook).

Корреляция запросов и расследование

Чтобы инциденты расследовались быстро, в контрактах и логировании закладывают:

correlation_id для каждого входного запроса.

Проброс контекста между сервисами.

Структурированные логи с обязательными полями (сервис, версия, endpoint, статус, длительность).

Связь с предыдущими статьями:

В статье про контракты вы обещали формат ошибок и идентификаторы.

Здесь вы показываете, как эти обещания превращаются в быстрый RCA и контроль SLO.

Инциденты: как команда действует, когда SLO падает

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

Минимальный жизненный цикл инцидента

!Как инцидент проходит через этапы от алерта до постмортема

Для ответа на интервью обычно достаточно описать процесс:

Обнаружение

Триаж и назначение ролей

Митигирование

Восстановление

Постмортем и предотвращение повторения

Severity и фокус на митигировании

Зрелая позиция EM:

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

Severity определяется влиянием на пользователя и бизнес-метрики, а не «страшностью» графиков.

Пример управленческого сигнала:

Если падает критичный SLI, мы включаем деградацию некритичного функционала и лимиты, чтобы защитить критичный путь.

Runbook и ownership

Runbook это пошаговая инструкция для on-call. На интервью полезно проговорить:

Где он хранится и кто обновляет.

Какие метрики и дешборды являются источником правды.

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

EM-сигнал: ownership не абстрактный. Понятно, какая команда отвечает за какой компонент, и как эскалировать.

Постмортем: обучаемся, а не ищем виноватых

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

Технические действия: фиксы, лимиты, улучшение деградации, тесты.

Операционные действия: новые алерты по SLO, улучшение runbook, обучение.

Продуктовые действия: возможно, пересмотр обещаний и SLO.

Практичная ссылка на культуру постмортемов: Postmortem Culture (Google SRE).

DR: восстановление после катастроф и непрерывность бизнеса

Disaster Recovery (DR) отвечает на вопрос: что если мы потеряем целый датацентр, регион или критичную систему хранения.

На интервью DR лучше обсуждать через два термина.

RPO и RTO

RPO (Recovery Point Objective) это сколько данных мы можем потерять по времени.

- Пример: RPO 5 минут означает, что при катастрофе допустима потеря последних 5 минут изменений.

RTO (Recovery Time Objective) это сколько времени допустимо восстанавливаться до работоспособного состояния.

- Пример: RTO 30 минут означает, что сервис должен вернуться в работу не позднее 30 минут.

EM-сигнал: вы не «делаете multi-region всегда», а выбираете стратегию под RPO/RTO и стоимость.

Стратегии DR и их компромиссы

| Стратегия | Идея | Плюсы | Минусы | Где уместна | |---|---|---|---|---| | Бэкапы и восстановление | Храним бэкапы, поднимаем заново | Дёшево, просто | Большой RTO, риск сюрпризов при restore | Нестрогие сервисы, маленькие команды | | Pilot light | Минимальная инфраструктура во втором регионе | Быстрее восстановления, чем только бэкапы | Нужно поддерживать базовую готовность | Сервисы со средними требованиями | | Warm standby | Постоянно поднят второй контур, но не под нагрузкой | Быстрый failover | Дороже, нужна синхронизация данных | Критичные сервисы | | Active-active | Два региона обслуживают трафик | Лучший RTO, гибкость | Очень дорого и сложно: консистентность, конфликты | Очень критичные системы при зрелой платформе |

Бэкапы, проверка восстановления и частая ловушка интервью

Бэкап без регулярного восстановления это гипотеза, а не гарантия.

На интервью хорошо звучит процесс:

Регулярные автоматические бэкапы с ретеншном.

Периодические учения restore в отдельном контуре.

Метрики по длительности восстановления и успешности.

Это напрямую связано с эксплуатацией и инцидентами: DR-план должен быть проверяемым.

Мини-кейс: сервис уведомлений, надёжность и эксплуатация

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

SLO

Пример:

Критичные уведомления: 99.9% доставлены за 30 секунд (за 28 дней).

API приёма задач: p95 < 200 мс.

Защита критичного пути

Разделение трафика: критичные и маркетинговые в разных очередях или с разным приоритетом.

Лимиты: per client и per campaign, чтобы маркетинг не съел провайдера.

Таймауты и circuit breaker на провайдерах.

Идемпотентность на приёме и у воркеров.

DLQ и процесс разбора.

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

Метрики очередей: lag, скорость обработки, процент ретраев.

Метрики провайдера: доля ошибок, таймауты, p95 задержки.

SLI по доставке: доля доставленных за 30 секунд.

Трейсы: путь от POST /send до вызова провайдера.

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

Метрики: Prometheus и визуализация через Grafana.

Трейсы: Jaeger или любой совместимый с OpenTelemetry бэкенд.

Инциденты и DR

При росте ошибок провайдера: включаем деградацию маркетинговых, сохраняем критичные.

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

DR для статусов и аудит-логов: задаём RPO/RTO, делаем бэкапы, тренируем восстановление.

Как это упаковать в интервью-ответ EM

Хорошее завершение блока надёжности и эксплуатации:

Назвать критичный SLO и SLI.

Перечислить 2–3 главные угрозы SLO.

Показать механизмы защиты: таймауты, лимиты, деградация, изоляция, идемпотентность.

Показать наблюдаемость: какие метрики алертят и как расследуем.

Сказать про инциденты: кто on-call, runbook, постмортем.

Закрыть DR: RPO/RTO и выбранная стратегия.

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

EM-уровень: компромиссы, стоимость, безопасность, roadmap и коммуникация решения

В предыдущих статьях курса мы разобрали «технический скелет» System Design ответа:

требования и SLO

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

данные, транзакции и консистентность

масштабирование и производительность

надежность, наблюдаемость, инциденты и DR

На интервью Engineering Manager в российском Big Tech этого часто недостаточно. Отличие сильного EM-ответа в том, что вы не просто проектируете систему, а показываете, что умеете управлять инженерным решением в реальной организации: выбирать компромиссы, считать стоимость, закладывать безопасность, строить roadmap и объяснять решение так, чтобы его могли принять и реализовать.

!Диаграмма показывает, что EM-аспекты пронизывают все технические решения

Как интервьюер отличает EM-уровень от «просто Senior»

Сигналы EM-уровня обычно такие:

Вы явно называете приоритеты и компромиссы, привязанные к бизнес-целям и SLO.

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

Вы говорите о стоимости как о первом ограничении, а не «потом оптимизируем».

Вы закладываете безопасность как часть требований и контрактов.

Вы предлагаете план поэтапного внедрения и эволюции.

Вы умеете «продать» решение: кратко, структурно, с рисками и планом проверки гипотез.

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

Компромиссы как управляемое решение, а не вкусовщина

На System Design интервью компромисс это выбор двух-трех вещей, которые вы защищаете любой ценой, и честное признание чем платите.

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

Чтобы не утонуть, держите в голове 6 осей, которые чаще всего конфликтуют:

Скорость вывода: быстрее MVP обычно означает меньше компонентов и гарантий.

Корректность: строгие инварианты часто увеличивают задержку и стоимость.

Доступность: высокая доступность повышает сложность и цену инфраструктуры.

Задержка: низкая p95/p99 задержка требует кэша, предвычислений и простых путей.

Масштаб: горизонтальный рост добавляет сложности данным, очередям и миграциям.

Эксплуатационная сложность: микросервисы, брокеры и шардирование увеличивают цену on-call.

Управленческий прием: выберите 2 оси как главные приоритеты и проговорите 1–2 оси как осознанный «долг».

Как фиксировать компромиссы на интервью

Формулировки, которые звучат зрело:

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

«Мы выбираем eventual consistency между OLTP и поисковым индексом, потому что требования допускают задержку обновления выдачи».

«Мы не идем в шардирование на старте: сначала реплики и партиционирование, потому что команда маленькая и цена шардирования в эксплуатации высокая».

ADR как язык решений

В больших компаниях решения живут дольше людей и команд, поэтому ценится привычка фиксировать почему так, а не только что сделано. Удобный паттерн: ADR (Architecture Decision Record).

Шаблон ADR в популяризации описан у Майкла Найгарда: Documenting Architecture Decisions.

На интервью ADR можно заменить короткой структурой «контекст → решение → альтернативы → последствия».

Стоимость: как говорить о деньгах без бухгалтерии

Стоимость в System Design это не только инфраструктура. Для EM важнее показать модель стоимости и понимание рычагов.

Из чего обычно состоит стоимость

Практичный список драйверов:

Compute: CPU и память для сервисов и воркеров.

Storage: объем данных, репликация, индексы, бэкапы.

Network: межсервисные вызовы, egress, интеграции с внешними провайдерами.

Платформенные зависимости: брокеры, поисковые кластеры, observability.

Лицензии: коммерческие СУБД, проприетарные решения.

Люди: сложность on-call, инциденты, время на поддержку и миграции.

EM-сигнал: вы включаете в стоимость «цену сложности». Это особенно важно для микросервисов, шардирования и актив-актив.

Как быстро прикинуть, что будет самым дорогим

На интервью достаточно качественной оценки:

Если система write-heavy с большими объемами событий, дорого будет хранение и запись, а также сеть и брокер.

Если read-heavy с низкой задержкой, дорого будет кэш и поддержание горячих данных.

Если много интеграций с внешними провайдерами, дорого будут ретраи, очереди, DLQ, а также мониторинг качества провайдера.

Типовые способы контролировать стоимость

Важно связывать оптимизацию стоимости с требованиями и SLO:

Ретеншн и tiering: хранить «горячее» отдельно от «холодного», удалять по политике.

Sampling в логах и трассировках: не собирать 100% там, где это не нужно для SLO.

Асинхронность и батчинг: снижать стоимость внешних вызовов и пиков.

Кэширование там, где допустима задержка актуализации.

Квоты и лимиты: защищают не только надежность, но и бюджет.

Если хотите назвать дисциплину, которая часто используется как общий язык для инженеров и финансов: FinOps Foundation.

Безопасность: минимальный уровень, который ожидают от EM

На EM-интервью безопасность редко проверяют глубоко криптографически, но часто проверяют зрелость: вы умеете выделять риски, закладывать controls и не ломать продукт.

Термины без путаницы

Аутентификация: кто ты.

Авторизация: что тебе можно.

Конфиденциальность: кто может прочитать данные.

Целостность: данные нельзя незаметно подменить.

Доступность: сервис должен работать, в том числе под атаками.

Что обязательно проговорить в любом дизайне

Базовые элементы, которые выглядят «по-взрослому»:

Классификация данных: что является персональными данными, что чувствительное.

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

Шифрование in transit: TLS между клиентом и сервисом, и между сервисами, если нужно.

Шифрование at rest: для чувствительных данных, плюс управление ключами.

Secrets management: секреты не в конфиге и не в репозитории.

Аудит: кто и когда совершил значимое действие.

Удобный общий ориентир по типовым уязвимостям приложений: OWASP Top 10.

Threat modeling как быстрый инструмент на интервью

Чтобы не превращать безопасность в чеклист, используйте простую механику:

Назовите 2–3 главных угрозы конкретного продукта.

Назовите меры снижения риска.

Обозначьте, что будет «не в MVP», и почему это допустимо.

Примеры угроз, которые уместны почти везде:

Утечка данных через неправильные права доступа.

Массовые злоупотребления API и исчерпание ресурсов.

Подмена событий или повтор запросов, приводящий к повторному эффекту.

Связь с предыдущими статьями:

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

Rate limiting это элемент защиты доступности.

Аудит-лог и корреляционные идентификаторы помогают расследовать инциденты безопасности.

Roadmap: как показать управляемую эволюцию системы

Сильный EM-ответ почти всегда включает этапность. Это показывает, что вы умеете доставлять ценность и снижать риски постепенно.

Типовой roadmap в 3 этапа

Удобная структура для интервью:

MVP

Hardening

Scale

Чтобы это звучало убедительно, каждый этап должен иметь:

цель

критерии готовности

главный риск, который вы снимаете

!Шаблон roadmap, который можно озвучить на интервью

Практичные техники безопасной эволюции

Интервьюеры любят, когда вы показываете, что изменения будут без даунтайма и без «большого взрыва»:

Expand-contract для схем и контрактов: сначала расширяем, потом переключаемся, потом удаляем старое.

Канареечные релизы и постепенный rollout.

Feature flags для управляемого включения функциональности.

Ссылки для опоры на известные практики:

Feature Toggles (Martin Fowler)

Parallel Change (Martin Fowler)

Как выбирать, что делать первым

Зрелая логика приоритизации:

Сначала закрываем критичный путь по SLO.

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

Затем оптимизируем стоимость на основании фактических метрик.

Это хорошо стыкуется с SRE-подходом через SLO и error budget: Service Level Objectives.

Коммуникация решения: как «продать» дизайн за 60 минут

Коммуникация на интервью это не «ораторское искусство», а способ сделать ваше решение проверяемым: интервьюер должен видеть причинно-следственную цепочку.

Структура рассказа, которую удобно держать в голове

Держите один и тот же порядок, и вы будете звучать уверенно:

Цель и пользователи

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

Нефункциональные приоритеты и SLO

Высокоуровневый дизайн и контракты

Deep dive в 1–2 риск-зоны

Надежность и эксплуатация

Компромиссы, стоимость, безопасность

Roadmap и риски

Три уровня детализации, чтобы не утонуть

Полезно проговаривать на интервью, что вы делаете «зум»:

Уровень 1: один слайд на доске с компонентами и потоками.

Уровень 2: один ключевой компонент в деталях.

Уровень 3: точечная деталь, которая критична для инварианта или SLO.

EM-сигнал: вы не «вываливаете» детали, а управляете глубиной.

Как говорить о рисках так, чтобы это было плюсом

Риск-ориентированная коммуникация выглядит сильнее, чем попытка сделать вид, что рисков нет:

Назовите 2–3 риска.

Для каждого дайте план проверки.

Для каждого дайте план снижения ущерба.

Примеры «плана проверки» на интервью:

Нагрузочное тестирование на пиковые сценарии.

Пилот на малой доле трафика.

Хаос-тесты на недоступность зависимости.

Мини-кейс: сервис уведомлений на EM-уровне

Мы использовали сервис уведомлений как сквозной пример в предыдущих статьях. Ниже пример того, как добавить EM-слой.

Компромиссы

Приоритет: доставка критичных уведомлений по строгому SLO.

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

Осознанный выбор: асинхронная отправка через очередь дает eventual consistency по статусам.

Стоимость

Главные драйверы: внешние провайдеры (SMS), объем статусов и ретраев, нагрузка на очереди.

Рычаги контроля: квоты per campaign, батчинг некритичных задач, ретеншн статусов, sampling трассировок в некритичном трафике.

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

Чувствительные данные: контактные данные получателя, содержимое сообщений.

Controls: минимальные права сервисов, аудит отправок, защита от злоупотреблений через rate limiting.

Антидубли: идемпотентность на POST /send и дедупликация у воркеров.

Roadmap

MVP

Hardening

Scale

Пример наполнения:

MVP: один канал, базовая очередь, статус accepted/sent/failed, минимальная наблюдаемость.

Hardening: разделение приоритетов, DLQ и процесс разбора, алерты по SLO, таймауты и circuit breaker для провайдера.

Scale: оптимизация стоимости, multi-provider стратегия, расширение статусов, ретеншн и архивирование.

Коммуникация

На доске: 6–8 блоков, один критичный путь, одна точка deep dive.

В конце: 2–3 компромисса, 2–3 риска, план по этапам.

Частые ошибки EM-кандидатов в этом блоке

«Оптимизируем потом» вместо явной модели стоимости и рычагов.

Безопасность как постскриптум, без привязки к данным и контрактам.

Roadmap без критериев готовности и без снятия рисков.

Отсутствие ownership: неясно, кто поддерживает, кто on-call, кто отвечает за DLQ и алерты.

Слишком много компонентов «на будущее», не соответствующих срокам и команде.

Как использовать ваш опыт QA и тимлида

Ваш бэкграунд помогает усилить EM-слой:

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

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

Безопасность можно связывать с процессами: контроль доступа к прод-данным, аудит, безопасные релизы.

Roadmap можно связывать с рисками: что проверяем первыми, где ставим guardrails.

Так вы показываете интервьюеру главное: вы не только умеете рисовать архитектуру, но и умеете сделать так, чтобы она реально работала и развивалась в условиях Big Tech.