System design на собеседовании
Масштабирование, кэширование, согласованность, микросервисы и оценка нагрузки.
- 01Как правильно логировать в бэкенд-сервисе?
Логи — события, по которым потом разбирают проблему. Уровни: ERROR — что-то сломалось и требует внимания, WARN — подозрительно, но работаем, INFO — значимые бизнес-события (заказ…
Junior - 02Что такое гексагональная архитектура (порты и адаптеры) и чем она отличается от слоистой?
Домен в центре и не зависит ни от чего внешнего. Он объявляет порты — интерфейсы на своём языке: входящие (сценарии использования) и исходящие (OrderRepository, PaymentGateway)…
Middle - 03Чем горизонтальное масштабирование отличается от вертикального?
Вертикальное (scale up) — мощнее одна машина; горизонтальное (scale out) — больше машин под балансировщиком.
Junior - 04Что утверждает CAP-теорема?
При разделении сети (P) распределённая система выбирает: отвечать, рискуя отдать устаревшее (A), или отказать, сохранив согласованность (C).
Middle - 05Что описывает eventual consistency?
Если записи прекратятся, все реплики со временем придут к одному значению. Сразу после записи разные клиенты могут видеть разное.
Middle - 06Зачем нужно кэширование и какие у него главные риски?
Кэш хранит результат дорогой операции ближе к потребителю: меньше задержка и нагрузка на источник. Главные риски — устаревшие данные и зависимость от кэша.
Junior - 07Что делает CDN?
CDN — сеть серверов по миру, которые кэшируют контент рядом с пользователями: меньше задержка и нагрузка на исходный сервер (origin).
Middle - 08Как сделать обработку запросов надёжной при сбоях и повторах?
Сбои неизбежны, поэтому: таймауты на каждый вызов, повторы с отсрочкой и джиттером, идемпотентность операций, чтобы повтор был безопасен, circuit breaker против долгих отказов и…
Middle - 09Как масштабировать чтение базы данных под высокой нагрузкой?
По порядку от дешёвого к дорогому: оптимизировать запросы и индексы → кэш → реплики для чтения → денормализация и модели чтения → шардирование.
Middle - 10Что в первую очередь покупает переход от монолита к микросервисам?
Микросервисы решают организационную задачу — независимую разработку и выкатку многими командами, а не задачу производительности.
Middle - 11По какому принципу правильнее проводить границы между сервисами?
По ограниченным контекстам (bounded context) и бизнес-возможностям: типичный сценарий должен выполняться внутри одного сервиса.
Middle - 12Какие признаки указывают на распределённый монолит?
Цена распределённой системы уплачена, а независимость не получена: общий релиз, общая база, синхронные цепочки, общая библиотека моделей.
Middle - 13Пользовательский сценарий последовательно вызывает пять сервисов, доступность каждого 99,9%. Какова примерная доступность сценария и что из этого следует?
В синхронной цепочке доступности перемножаются: 0,999⁵ ≈ 0,995. Простой вырастает впятеро — с ~43 минут до ~3,6 часа в месяц.
Middle - 14Почему действует правило «одна база данных на сервис»?
Своя база нужна ради независимого изменения схемы и защиты инвариантов: только владелец пишет в свои данные по своим правилам. Дело не в нагрузке.
Middle - 15Стартап начинает новый продукт и спрашивает: сразу микросервисы или монолит? Что вы порекомендуете и почему?
Модульный монолит: границы внутри процесса стоят дёшево и переносятся рефакторингом, а границы сервисов закрепляются сетевым контрактом и стоят дорого.
Middle - 16Какие HTTP-методы идемпотентны?
Идемпотентны GET, HEAD, OPTIONS, PUT, DELETE: повтор запроса оставляет сервер в том же состоянии. POST и обычно PATCH — нет.
Middle - 17Клиент отправил POST для создания заказа, не дождался ответа из-за таймаута и повторил запрос. Как правильно не допустить второго заказа?
Клиент генерирует ключ идемпотентности (UUID) на операцию и передаёт его в заголовке; сервер сохраняет ключ и результат в одной транзакции с созданием заказа и на повтор…
Middle - 18Лента с бесконечной прокруткой использует LIMIT 20 OFFSET N. С ростом N страницы отдаются всё медленнее, а пользователи жалуются на дубли. В чём причина и что делать?
OFFSET заставляет базу пройти и отбросить N строк — чем глубже страница, тем медленнее; а вставки между запросами сдвигают окно — отсюда дубли и пропуски. Решение — keyset…
Middle - 19Какие изменения REST API обратно совместимы для существующих клиентов?
Добавлять можно (новое необязательное поле в ответе, новый эндпоинт, новый необязательный параметр); удалять, переименовывать, менять тип и ужесточать — нельзя.
Middle - 20Какой вопрос лучше всего определяет выбор между синхронным вызовом и событием через брокер?
Главный вопрос: нужен ли ответ немедленно, чтобы продолжить? Нужен — синхронный вызов (REST, gRPC). Не нужен — событие через брокер.
Middle - 21Как гарантировать, что изменение вашего API не сломает потребителей, которых вы не контролируете?
По уровням: дисциплина совместимых изменений → схема как источник истины → автоматическая проверка совместимости в CI → контрактные тесты от потребителей.
Middle - 22Что означает CQRS?
CQRS — разные модели для записи (команды) и чтения (запросы): запись защищает инварианты на нормализованной модели, чтение берёт денормализованные представления под экраны.
Middle - 23Как соотносятся CQRS и Event Sourcing?
Это независимые решения, которые часто применяют вместе. CQRS — разделение моделей чтения и записи; event sourcing — хранение изменений как неизменяемого журнала событий вместо…
Middle - 24Что относится к обязательной технической механике Event Sourcing?
Обязательная механика: снапшоты (не проигрывать миллион событий), оптимистичная блокировка по версии потока (конкурентные команды), версионирование и апкастинг событий. Записанные…
Middle - 25После перехода на отдельное хранилище для чтения пользователи жалуются: сохранённое изменение не сразу видно в списке. Как правильно к этому отнестись?
Отставание модели чтения — свойство полного CQRS, а не дефект: его закладывают в продукт и интерфейс.
Middle - 26Какие требования предъявляются к проекции, строящей модель чтения из потока событий?
Проекция строит модель чтения из потока событий. Требования: идемпотентность, порядок внутри агрегата (партиционирование по его id), наблюдаемое отставание и возможность…
Middle - 27Когда Event Sourcing и полный CQRS применять не стоит, и что делать вместо этого?
Не нужно в CRUD-домене, при требовании немедленной согласованности и без опыта эксплуатации асинхронных конвейеров. Вводить по нарастающей и точечно.
Senior - 28Чем наблюдаемость (observability) отличается от мониторинга?
Мониторинг отвечает на заранее известные вопросы (дашборды и алерты под известные отказы). Наблюдаемость — свойство системы отвечать на непредусмотренные вопросы по её телеметрии.
Middle - 29Команда добавила в метрику задержки метку с идентификатором пользователя, чтобы «удобнее расследовать инциденты». Что произойдёт?
Каждая уникальная комбинация меток — отдельный временной ряд. Метка с user_id превращает одну метрику в миллионы рядов: растут память, диск и время запросов, система мониторинга…
Middle - 30Что верно про измерение времени ответа сервиса?
Смотрим перцентили (p50, p95, p99), а не среднее; перцентили не усредняются — считаем из гистограмм; успешные и ошибочные запросы — раздельно.
Middle - 31Что такое error budget и зачем он нужен?
Бюджет ошибок = 100% − SLO. При SLO 99,9% за 30 дней можно «потратить» ~43 минуты недоступности. Это инструмент решений: бюджет есть — выкатываем смелее, кончился — приоритет…
Middle - 32Дежурных будят алерты «загрузка CPU выше 90%», которые в большинстве случаев ни к чему не приводят. Как правильно перестроить алертинг?
Алертить на симптомы (пользователям плохо: ошибки, задержка, нарушение SLO), а не на причины (CPU 90%). Высокая загрузка может быть нормой.
Middle - 33В цепочке из пяти сервисов у пользователей выросло время ответа. Как вы будете искать причину и что для этого должно быть построено заранее?
Метрики показывают, где и когда выросло; трейсы — в каком шаге ушло время; логи по trace_id — почему. Работает, только если корреляция построена заранее.
Middle - 34Во время rolling update в проде одновременно работают старая и новая версии сервиса. Какое требование из этого следует?
Во время выкатки работают обе версии, поэтому совместимость нужна в обе стороны: старая переживает данные и запросы новой, новая — старой.
Middle - 35Нужно переименовать колонку name в full_name без простоя при rolling-выкатке. Какая последовательность верна?
Expand–contract в пять шагов: добавить full_name → писать в обе колонки → перелить старые данные порциями → читать из новой → удалить name отдельным поздним релизом.
Middle - 36Что верно про feature flags?
Флаги отделяют выкатку кода от включения функции: код едет в прод выключенным, включение и откат — за секунды, без деплоя.
Middle - 37Чем canary-выкатка принципиально отличается от blue-green?
Blue-green — второй полный комплект и переключение всего трафика разом: мгновенный откат, но ошибку сразу видят все. Canary — новая версия на малую долю трафика, сравнение метрик…
Middle - 38Как вы спланируете выкатку изменения, затрагивающего и код, и схему базы, чтобы её можно было безопасно откатить?
Миграция и код — разными релизами; схема меняется через expand–contract; необратимые шаги (удаление колонок, данных) — в самом конце и с задержкой.
Middle - 39Эндпоинт GET /orders/{id} проверяет, что пользователь аутентифицирован, и возвращает заказ по идентификатору. Что здесь не так?
Проверено «кто ты» (аутентификация), но не «можно ли тебе этот заказ» (авторизация): любой вошедший пользователь читает чужие заказы, перебирая id. Это IDOR — Broken Access…
Middle - 40Что верно про использование JWT для аутентификации?
JWT самодостаточен — сервер проверяет подпись без базы. Отсюда главный минус: его нельзя отозвать до истечения. Решение — короткий access-токен (минуты) и отзываемый refresh…
Middle - 41Чем bcrypt и argon2 принципиально отличаются от SHA-256 применительно к хранению паролей?
SHA-256 быстрый — это хорошо для контрольных сумм и плохо для паролей: утёкшую базу перебирают миллиардами вариантов в секунду. bcrypt, scrypt и argon2 намеренно медленные и…
Middle - 42Разработчик случайно закоммитил ключ доступа к платёжному провайдеру и через час удалил его следующим коммитом. Что нужно сделать?
Секрет в истории git — утёк. Единственное надёжное действие — отозвать и перевыпустить (ротация), затем проверить журналы использования ключа.
Middle - 43Что относится к рискам цепочки поставок ПО (Software Supply Chain Failures, A03 в OWASP Top 10:2025)?
Всё, что попадает в продукт извне: зависимости (включая транзитивные), артефакты сборки, образы, сам конвейер CI/CD. В OWASP Top 10:2025 — отдельная категория A03.
Middle - 44Какие меры безопасности вы заложите при проектировании публичного REST API с личным кабинетом пользователя?
По слоям: контроль доступа → аутентификация → ввод и транспорт → что отдаём наружу → эксплуатация.
Middle - 45Сервисом пользуются 10 млн активных пользователей в сутки, каждый совершает около 20 целевых действий. Какой примерно QPS в пике при коэффициенте пиковости 3?
10 млн × 20 = 200 млн запросов в сутки; в сутках ≈ 10⁵ секунд → ~2 000 QPS в среднем; пиковость 3 → ~6 000 QPS.
Middle - 46Какие порядки величин стоит держать в голове при оценке на салфетке?
Важны соотношения: память ~100 нс, SSD ~100 мкс (в тысячу раз медленнее), HDD ~10 мс (ещё в сто), сеть внутри дата-центра ~0,5 мс, другой континент ~100+ мс.
Middle - 47Сервис принимает 100 млн сообщений в сутки по 1 КБ. Сколько примерно места потребуется за год и какой множитель забывают чаще всего?
10⁸ × 1 КБ = 100 ГБ в сутки → ~36 ТБ в год → ~100 ТБ с тройной репликацией. Чаще всего забывают множитель репликации.
Middle - 48Сервер приложений загружен на 30% по CPU, но задержки растут, а пул соединений к базе занят полностью. Что даст добавление ещё нескольких серверов приложений?
Ничего хорошего: узкое место — база (пул соединений занят, CPU приложения свободен). Новые экземпляры добавят соединений и конкуренции за ту же базу — может стать даже хуже.
Middle - 49Вас просят спроектировать ленту новостей. С чего вы начнёте оценку и какие вопросы зададите до выбора архитектуры?
Сначала вопросы и допущения вслух, потом цепочка от аудитории к QPS, хранению и трафику, и обязательно вывод: где узкое место и что из этого следует для архитектуры.
Middle - 50Какую задачу решает consistent hashing по сравнению с обычным hash(key) % N?
При hash % N смена N переносит почти все ключи; на кольце consistent hashing переезжает только ~1/N — ключи с дуги нового или ушедшего узла.
Middle - 51Почему для горизонтального масштабирования сервис делают stateless?
Stateless — состояние не в памяти экземпляра, а в базе, кэше, брокере или токене. Экземпляры взаимозаменяемы: запрос можно отправить в любой.
Middle - 52В системе с N репликами при каком условии чтение гарантированно увидит последнюю подтверждённую запись?
Если R + W > N, множества реплик для чтения и записи пересекаются — чтение застанет хотя бы одну реплику с последней подтверждённой записью.
Middle - 53Какие промежуточные гарантии находятся между строгой и итоговой согласованностью?
Согласованность — спектр: между линеаризуемостью и итоговой лежат read-your-writes, монотонные чтения, причинная согласованность.
Middle - 54Чем write-through отличается от write-back при кэшировании записи?
Write-through — запись синхронно в кэш и хранилище: согласованно и надёжно, но каждая запись медленная. Write-back — запись в кэш, в хранилище позже: быстро и объединяет…
Middle - 55Почему инвалидацию кэша считают одной из самых сложных задач и что помогает на практике?
Сложно из-за зависимостей: кэшированное значение собрано из нескольких сущностей, и отследить все ключи, затронутые изменением строки, трудно.
Middle - 56В каких состояниях бывает circuit breaker и как он между ними переходит?
Закрыт — вызовы идут, ошибки считаются; порог превышен — открыт: вызовы сразу отклоняются; после паузы — полуоткрыт: несколько пробных вызовов решают, закрыться или снова…
Middle - 57Почему для надёжной публикации события после изменения данных применяют transactional outbox, а не двухфазный коммит?
Проблема двойной записи: между коммитом в базу и отправкой в брокер можно упасть. Outbox пишет событие строкой в ту же транзакцию, а отдельный процесс публикует его в брокер.
Senior - 58Нагрузка превысила возможности сервиса. Какие приёмы позволяют деградировать управляемо, а не упасть целиком?
Частичный отказ лучше полного: сбрасывать лишнюю нагрузку, отключать второстепенное, отдавать устаревшие данные.
Middle - 59Что описывают три буквы в CAP?
C — согласованность (каждое чтение видит последнюю запись), A — доступность (каждый запрос получает ответ), P — устойчивость к разделению сети.
Junior - 60Что означает идемпотентность операции?
Операция идемпотентна, если состояние после одного и нескольких выполнений одинаково — повтор безопасен.
Junior - 61Что такое микросервисная архитектура?
Система из независимо развёртываемых сервисов, каждый владеет своими данными и отвечает за бизнес-возможность. Ключевое — независимость, а не размер.
Junior - 62Что означает буква R в аббревиатуре REST применительно к проектированию API?
REST — Representational State Transfer: ресурсы адресуются URL, действия выражаются методами HTTP, клиент работает с представлениями ресурсов.
Junior - 63Что разделяет подход CQRS?
Команды меняют состояние, запросы возвращают данные — и модели для них разные.
Junior - 64Какие три сигнала составляют основу наблюдаемости?
Метрики — дешёвые агрегаты для алертов и трендов; логи — подробности событий; трейсы — путь одного запроса через сервисы.
Junior - 65Что такое rolling update при выкатке новой версии?
Экземпляры заменяются постепенно: поднимается новый, проходит readiness, старый снимается. Сервис отвечает всё время.
Junior - 66Чем аутентификация отличается от авторизации?
Аутентификация — «кто ты» (проверка личности); авторизация — «что тебе можно» (проверка прав на действие и ресурс).
Junior - 67Сервис обрабатывает около 8 640 000 запросов в сутки. Каков примерно средний QPS?
В сутках 86 400 с → 8,64 млн / 86 400 = 100 QPS.
Junior - 68Сервис планируют масштабировать горизонтально. Какие его свойства придётся устранить, чтобы инстансы можно было свободно добавлять и снимать?
Мешает всё, что привязывает запрос или работу к экземпляру: сессии в памяти, файлы на локальном диске, локальный кэш изменяемых данных, планировщик задач без координации.
Middle - 69Данные шардированы по хешу от идентификатора клиента. Несколько крупных клиентов дают около 80% нагрузки, и она приходится на один шард. Что здесь поможет?
Перекос создаёт сам ключ: данные крупного клиента по определению в одном шарде. Добавление шардов не поможет — лечат гранулярностью ключа и выделением тяжёлых клиентов.
Senior - 70Сервис работает на двадцати инстансах. Добавление ещё десяти не уменьшает время ответа. Как вы будете искать причину и что предпримете?
Ограничение не в приложении: нужно разложить время запроса и найти насыщенный общий ресурс — чаще всего база или пул соединений.
Middle - 71Почему условие R + W > N само по себе не даёт линеаризуемости?
Кворум гарантирует свежесть, но не порядок: прерванные и конкурентные записи, а также нестрогий кворум ломают линеаризуемость.
Senior - 72Пользователь публикует комментарий и должен сразу видеть его в ленте, а остальным допустима задержка в несколько секунд. Какие гарантии согласованности вы заложите и как это реализуете?
Требование несимметрично: автору — чтение своих записей, остальным — согласованность в конечном счёте. Линеаризуемость на всех чтениях ленты не нужна и дорога.
Middle - 73Популярный ключ истекает, и сотни параллельных запросов одновременно уходят в базу за одним значением. Какие приёмы защищают от этого?
Популярный ключ истёк — сотни запросов разом идут в базу. Защита: разброс TTL, пересчёт в один поток (single flight), выдача устаревшего с фоновым обновлением.
Middle - 74После обновления строки приложение записывает новое значение в кэш. Изредка в кэше навсегда остаётся устаревшее значение. Что происходит и как правильно?
Гонка: читатель прочитал старое из базы, писатель обновил базу и кэш, читатель записал старое поверх. Лечится удалением ключа вместо перезаписи плюс TTL и версиями.
Senior - 75Каталог товаров: 95% запросов — чтение, описания меняются редко, но изменение цены должно быть видно пользователям в течение минуты. Как вы спроектируете кэширование?
Разделить данные по требуемой свежести: картинки и статика — CDN с версионированными именами; описания — кэш на десятки минут; цена и остаток — отдельный ключ с коротким TTL и…
Middle - 76Внешний платёжный провайдер начал отвечать за 30 секунд вместо 200 миллисекунд. Через минуту сервис перестал отвечать вообще, включая страницы, не связанные с оплатой. Что произошло?
Медленная зависимость выедает общий пул потоков и соединений: каждый запрос держит поток в 150 раз дольше, и сервис перестаёт обслуживать даже страницы без оплаты.
Middle - 77В цепочке из трёх сервисов каждый повторяет неудачный вызов до трёх раз. Нижний сервис кратковременно деградировал. Чем это закончится?
Повторы умножаются по цепочке: 3 уровня × 3 попытки = до 27 запросов вниз. Кратковременная деградация превращается в отказ.
Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.