Вопросы на собеседовании: Архитектор решений
100 реальных вопросов с образцовыми ответами и пояснениями для уровня Middle.
Смотреть пример резюме: Архитектор решений →Тренировка флешкарточками
Интервальное повторение · Hunter Pass
Вопросы
Горизонтально масштабируемая система позволяет добавлять взаимозаменяемые инстансы и распределять работу между ними.
- Обработка запросов не хранит локальное состояние или выносит общее состояние во внешние системы, доступные всем инстансам.
- Распределение нагрузки, партиционирование и асинхронная обработка не дают одному узлу получить всю работу.
- Зависимости, включая базы и очереди, тоже должны масштабироваться, поскольку реплики приложения не уберут узкое место ниже по цепочке.
Зачем это спрашивают: Интервьюер проверяет понимание горизонтального масштабирования как свойства всей системы, а не простого добавления серверов.
Эффективное автомасштабирование объединяет полезный сигнал спроса, правило масштабирования и безопасный ввод новых инстансов в работу.
- Метрики вроде частоты запросов, глубины очереди или CPU должны отражать нагрузку и поступать без большой задержки.
- Пороги, target tracking, интервалы стабилизации, минимум и максимум ёмкости управляют поведением масштабирования.
- Новым инстансам нужны автоматическая конфигурация, health checks и время на запуск до получения трафика.
Зачем это спрашивают: Сильный ответ охватывает сигналы, правила и готовность инстансов, а не считает автомасштабирование одним переключателем.
Stateful-компоненты должны сохранять владение, согласованность и перенос данных при изменении ёмкости.
- Stateless-реплику обычно можно заменить, потому что постоянное состояние хранится снаружи.
- Stateful-узел может владеть разделами, сессиями или локальными данными, которые нужно реплицировать или переназначать.
- Поэтому балансировка и переключение требуют координации, чтобы не потерять записи и не получить двойное владение или недоступные данные.
Зачем это спрашивают: Интервьюер оценивает, связываете ли вы состояние с координацией и переносом данных при масштабировании.
Алгоритмы балансировки выбирают таргеты по заданному представлению о равномерности или текущей нагрузке.
- Round robin перебирает здоровые таргеты, а weighted round robin отправляет больше трафика более мощным таргетам.
- Least connections выбирает таргет с меньшим числом активных соединений и подходит для запросов разной длительности.
- Consistent hashing сопоставляет ключ со стабильным таргетом и уменьшает перераспределение при изменении их набора.
Зачем это спрашивают: Сильный ответ различает механику нескольких алгоритмов и не объявляет один из них универсально лучшим.
Backpressure замедляет производителей при насыщении потребителей, а сброс нагрузки отклоняет работу, которую система не может безопасно выполнить.
- Ограниченные очереди, сигналы управления потоком и снижение приёма не дают отставанию расти бесконечно.
- Сброс нагрузки рано отклоняет выбранные запросы, сохраняя ёмкость для критичной работы.
- Оба подхода удерживают задержку под контролем и сохраняют стабильность, явно обрабатывая перегрузку вместо каскадного сбоя.
Зачем это спрашивают: Интервьюер проверяет знание способов сохранить управляемость масштабируемой системы, когда спрос превышает ёмкость.
При cache-aside приложение загружает данные в кеш только после промаха.
- Сначала приложение проверяет кеш, а при отсутствии ключа читает базу данных.
- Затем оно сохраняет результат базы с подходящим TTL и возвращает его.
- Записи меняют источник истины и инвалидируют или обновляют связанные элементы кеша, чтобы ограничить устаревание.
Зачем это спрашивают: Сильный ответ описывает и путь чтения, и работу с согласованностью при записи.
Write-through синхронно обновляет кеш и постоянное хранилище, а write-behind сохраняет кешированные записи позже.
- Write-through поддерживает актуальность основного хранилища, но добавляет его задержку к запросу.
- Write-behind сглаживает всплески и снижает задержку за счёт асинхронной пакетной записи.
- Write-behind требует надёжного буфера и обработки сбоев, иначе ещё не сохранённые данные кеша можно потерять.
Зачем это спрашивают: Интервьюер оценивает понимание влияния обеих стратегий записи на согласованность и сохранность.
Инвалидация использует срок действия, явное удаление или версионированные ключи, чтобы устаревшие элементы не жили бесконечно.
- Истечение по TTL просто реализовать, но данные могут оставаться устаревшими до конца таймера.
- Явная инвалидация удаляет или обновляет известные ключи при изменении источника.
- Версионированные ключи направляют новые запросы на чтение в новое пространство имён, пока старые записи истекают сами.
Зачем это спрашивают: Сильный ответ называет конкретные механизмы инвалидации и их поведение по свежести.
Cache stampede возникает, когда после истечения записи много запросов одновременно вычисляют одно значение.
- Одновременные промахи могут перегрузить базу или origin дублирующей работой.
- Объединение запросов или распределённая блокировка позволяют одному обработчику обновить значение, пока остальные ждут.
- Разброс TTL, раннее обновление и краткая отдача устаревших данных не дают истечениям совпасть.
Зачем это спрашивают: Интервьюер проверяет, распознаёте ли вы распространённый сбой, создаваемый полезным механизмом кеширования.
Origin shielding и многоуровневое кеширование добавляют промежуточный слой кеша между пограничными узлами и origin.
- Множество промахов на пограничных узлах объединяются в региональном или shield-кеше до обращения к origin.
- Схема сокращает соединения с origin и защищает его при массовых промахах кеша.
- Ключи, TTL и инвалидации должны оставаться согласованными на всех уровнях кеша.
Зачем это спрашивают: Сильный ответ объясняет, как дополнительный уровень кеша сокращает дублирующий трафик к origin.
Read replica представляет копию базы, которая получает изменения с primary и обслуживает чтение.
- Приложения направляют подходящие запросы на реплики, чтобы уменьшить нагрузку чтения на primary.
- Из-за задержки репликации на реплике может ещё не быть последней зафиксированной записи.
- Записи обычно остаются на primary, если база не поддерживает другую multi-writer модель.
Зачем это спрашивают: Интервьюер проверяет понимание и масштабирования чтения, и влияния задержки репликации на согласованность.
Синхронная репликация ждёт подтверждения реплики перед ответом о записи, а асинхронная не ждёт.
- Синхронное подтверждение снижает риск потери уже подтверждённых записей при отказе primary.
- Задержка записи зависит от времени ответа реплики и расстояния по сети.
- Асинхронная репликация снижает задержку записи, но после сбоя возможны потеря свежих изменений или устаревшее чтение.
Зачем это спрашивают: Сильный ответ связывает момент подтверждения с задержкой, согласованностью и восстановлением.
Шардинг горизонтально делит набор данных между независимыми разделами базы, называемыми шардами.
- Каждый шард хранит только строки, назначенные ему по ключу шардинга или правилу маршрутизации.
- Шардинг распределяет объём хранения и нагрузку записи за пределы одного узла базы.
- Межшардовые запросы, транзакции, ребалансировка и горячие разделы становятся заботой приложения или платформы.
Зачем это спрашивают: Интервьюер оценивает понимание цели масштабирования и операционной сложности шардинга.
Хороший ключ равномерно распределяет нагрузку и данные и при этом поддерживает частые запросы.
- Высокая кардинальность даёт достаточно разных значений для распределения записей по разделам.
- Равномерная частота запросов не позволяет одному популярному значению создать горячий раздел.
- Запросы с ключом могут обратиться к одному разделу вместо сканирования или координации нескольких.
Зачем это спрашивают: Сильный ответ связывает выбор ключа с распределением, горячими разделами и маршрутизацией запросов.
Пул повторно использует ограниченный набор соединений с базой для множества запросов приложения.
- Повторное использование убирает задержку и стоимость открытия нового соединения для каждого запроса.
- Лимиты пула защищают базу от большего числа параллельных соединений, чем она способна обработать.
- Размер пула, таймаут запроса и число инстансов нужно согласовать, поскольку каждая реплика приложения создаёт свой пул.
Зачем это спрашивают: Интервьюер проверяет понимание числа соединений как общего ограничения ёмкости базы.
Теорема CAP утверждает, что во время сетевого разделения распределённая система выбирает между согласованностью и доступностью.
- Согласованность означает, что каждое успешное чтение видит последнее зафиксированное значение в рамках обсуждаемой модели.
- Доступность означает, что каждый запрос к исправному узлу получает ответ без ошибки.
- Устойчивость к разделению неизбежна в реальной сети, поэтому практический выбор задаёт поведение продукта при таком сбое.
Зачем это спрашивают: Сильный ответ указывает условие сетевого разделения и не повторяет неточное утверждение о свободном выборе любых двух свойств всегда.
Eventual consistency допускает временное расхождение реплик, но предполагает их схождение после прекращения обновлений.
- Чтение может вернуть старое значение, пока репликация или асинхронная обработка догоняет изменения.
- Правила разрешения конфликтов и порядка определяют результат параллельных обновлений.
- Системы часто добавляют гарантии read-your-writes или монотонного чтения там, где этого требует пользовательский опыт.
Зачем это спрашивают: Интервьюер оценивает понимание eventual consistency как заданной модели схождения, а не случайной несогласованности.
CQRS разделяет модели и пути команд, меняющих состояние, и запросов, читающих состояние.
- Модель записи проверяет бизнес-правила и фиксирует принятые изменения.
- Одна или несколько моделей чтения оптимизированы под запросы и могут обновляться асинхронно.
- Разделение позволяет независимо масштабировать чтение и запись, но добавляет синхронизацию и работу с согласованностью.
Зачем это спрашивают: Сильный ответ объясняет разделение моделей и цену поддержания актуальности представлений чтения.
Event Sourcing хранит упорядоченную историю доменных событий как достоверную запись всех изменений состояния.
- Текущее состояние восстанавливают повторным применением событий или читают из построенных по ним проекций.
- Журнал событий даёт историю аудита и позволяет позже строить новые проекции.
- Эволюция схем событий, повторное применение, рост хранилища и случайные чувствительные данные требуют отдельного управления.
Зачем это спрашивают: Интервьюер проверяет, отличаете ли вы Event Sourcing от простой публикации уведомлений после обновления базы.
Очередь распределяет каждое сообщение одному конкурирующему потребителю, а публикация-подписка доставляет событие нескольким подпискам.
- Потребители очереди делят общий backlog, поэтому их добавление увеличивает производительность обработки.
- Каждая подписка pub-sub имеет независимый путь доставки для своей группы потребителей.
- Оба паттерна ослабляют связанность, но выражают распределение работы один к одному и уведомление один ко многим.
Зачем это спрашивают: Сильный ответ ясно отличает конкурирующее потребление от fan-out доставки.
Закрытые вопросы
- 21
Что означают гарантии доставки at-most-once, at-least-once и exactly-once?
- 22
Что делает потребителя сообщений идемпотентным?
idempotency - 23
Как партиции влияют на порядок и масштабирование в Kafka?
kafkascalabilitypartitioning - 24
Что такое dead-letter queue?
data-structures - 25
Что такое паттерн Saga для распределённых транзакций?
sagadistributedtransactions - 26
Какую роль играет шина событий, такая как AWS EventBridge?
- 27
Какие обязанности стоит размещать в API gateway?
gatewayapi-gatewayapi - 28
Какую проблему решает service mesh?
service-mesh - 29
Чем control plane Istio отличается от data plane?
- 30
Чем REST, gRPC и GraphQL отличаются как стили API?
restgraphqlgrpc - 31
Чем алгоритмы rate limiting token bucket и leaky bucket отличаются друг от друга?
tokensrate-limiting - 32
Как таймауты, повторы и circuit breaker работают вместе?
resilience - 33
Как связаны пользователи, роли и политики IAM?
identity-access - 34
Что означает принцип наименьших привилегий в IAM?
least-privilegeidentity-accessdesign - 35
Что такое федерация идентичности и единый вход в облаке?
- 36
Чем шифрование при хранении отличается от шифрования при передаче?
encryptionrest - 37
Что такое envelope encryption с облачным KMS?
encryption - 38
Какие возможности должен предоставлять сервис управления секретами?
secrets - 39
Как сегментация сети, security groups, network ACL и WAF создают многоуровневую защиту?
networking - 40
Что такое моделирование угроз в архитектуре решений?
threat-modelingarchitecture - 41
Что такое многоуровневая архитектура?
architecture - 42
Чем multi-region архитектуры active-active и active-passive отличаются друг от друга?
cloud-regionsmulti-region - 43
Что такое RTO и RPO в disaster recovery?
disaster-recovery - 44
Каковы основные облачные стратегии disaster recovery?
- 45
Каковы распространённые стратегии миграции, известные как 7 Rs?
migrationscloud-migration - 46
Что такое паттерн Strangler Fig для миграции приложения?
migrationcloud-migrationmigrations - 47
Какую роль change data capture играет в миграции данных?
migrationscloud-migration - 48
Каковы основные механизмы оптимизации облачных затрат?
cost-optimizationoptimizationfinops - 49
Как шесть столпов AWS Well-Architected влияют на архитектурный обзор?
designwell-architected - 50
Как проходит обзор по AWS Well-Architected Framework?
well-architectedconcurrency - 51
У вас шесть инженеров, и за четыре месяца нужно запустить B2B SaaS для 200 арендаторов, причём один арендатор будет создавать половину трафика. Как спроектировать мультитенантность без лишнего усложнения?
designcloud-modelscloud - 52
Спроектируйте checkout, где платёжные callback могут дублироваться, запас товара ограничен, а клиент должен получить ответ за три секунды, даже если fulfillment недоступен.
designcallbacks - 53
Пользователи загружают файлы до 5 ГБ, обработка может занимать 15 минут, а API должен отвечать за две секунды. Как спроектировать путь в AWS?
designapiconcurrency - 54
Маркетплейс должен отправлять email, SMS и push-уведомления для двух миллионов событий в день, учитывать настройки и доставлять срочные предупреждения безопасности за одну минуту. Как это организовать?
alerting - 55
IoT-платформа принимает 100 000 событий в секунду с пятикратными всплесками, должна сохранять порядок для каждого устройства и поддерживать быстрые предупреждения и недорогое хранение семь лет. Что вы построите?
retentionalerting - 56
Веб-продукт работает в США, Европе и Азии, страницы на 90 процентов статические, а персонализированные ответы API должны укладываться в 300 мс без нарушения резидентности данных ЕС. Как организовать глобальную доставку?
discoveryapi - 57
Нужно интегрироваться с 50 B2B-клиентами через REST, SOAP и ночные SFTP-файлы, причём сбой одного клиента не должен блокировать остальных. Как спроектировать интеграционный слой?
designrest - 58
Ecommerce-платформе нужна строгая согласованность заказов и платежей, а каталог имеет разные атрибуты в тысячах категорий и в десять раз больше чтений, чем записей. Вы выберете SQL или NoSQL?
sqlnosqlconsistency - 59
Checkout требует решения антифрод-системы до платежа, но налоговые документы, бонусы и письма могут быть готовы за пять минут. Какие взаимодействия сделать синхронными, а какие асинхронными?
async - 60
У команды из восьми инженеров есть шесть месяцев на запуск маркетплейса с неизвестным спросом. Вы начнёте с монолита или микросервисов и как сохраните варианты масштабирования?
microservicesmonolithscaling - 61
Платформе нужны публичный API для партнёров, низкая задержка между внутренними сервисами и dashboard, объединяющий backend-ресурсы. Как выбрать между REST, gRPC и GraphQL?
restgraphqlgrpc - 62
Платформа заказов создаёт 10 000 событий в секунду, требует порядка для заказа и повтора за семь дней, но команда уже эксплуатирует очереди AWS и не знает Kafka. Стоит ли внедрять Kafka?
kafkadata-structures - 63
Поддержке нужен быстрый dashboard с фильтрами по заказам, записи требуют строгой валидации, а dashboard может отставать на 30 секунд. Оправдан ли CQRS?
validationcqrs - 64
API цен получает 50 000 чтений в секунду, цены меняются каждую минуту, а показывать цену старше двух минут нельзя. Как безопасно организовать кеширование?
pricingapicaching - 65
Kubernetes API обычно использует 20 процентов мощности, но получает непредсказуемые восьмикратные всплески, а CPU плохо отражает стоимость запроса. Как совместить балансировку и автомасштабирование?
load-balancingcapacityscaling - 66
Checkout-системе нужны доступность 99,95 процента, RPO менее пяти минут и пользователи на двух континентах, причём заказы ЕС должны оставаться в Европе. Стоит ли запускать active-active?
system-designcloud-regions - 67
PostgreSQL-база заказов достигает 75 процентов CPU в пики, 70 процентов трафика приходится на чтение, а нагрузка должна утроиться за год. Какую последовательность масштабирования вы предложите?
databasepostgresscaling - 68
Спроектируйте хранение и доставку приватных исходных видео и публичных превью размером от 100 МБ до 20 ГБ с частым глобальным просмотром. Что должно быть в объектном хранилище и CDN?
designcdncloud-storage - 69
Двадцать внешних партнёров вызывают API пяти команд, каждому нужны отдельные квоты и учётные данные, а API развиваются с разной скоростью. Что вы разместите в API Gateway?
gatewayapi-gatewayapi - 70
Платформенная команда из трёх человек обслуживает 12 Kubernetes-сервисов в EKS и рассматривает Istio для retries, mTLS и разделения трафика. Стоит ли внедрять service mesh?
kubernetesservice-meshdecision-making - 71
Двух регулируемых клиентов нужно перевести из общей SaaS-базы на выделенную изоляцию, при этом 300 арендаторов остаются в пуле, а все получают одинаковые релизы. Как избежать форка продукта?
databasecloudcloud-models - 72
Вы проверяете обмен документами с публичными ссылками, командными правами и антивирусным сканированием. Как провести моделирование угроз до реализации?
code-review - 73
При региональном сбое или ransomware нельзя потерять больше 15 минут данных заказов, а checkout должен восстановиться за 60 минут. Какой disaster recovery дизайн вы предложите?
designcloud-regionsincidents - 74
Заказы ведутся в AWS, CRM работает в Azure, а аналитика в GCP; обновления должны приходить за пять минут, а удаление клиента распространяться повсюду. Как спроектировать межоблачный поток данных?
design - 75
Три команды разрабатывают заказы, остатки и fulfillment, но дизайн использует общую базу, и изменения часто ломают процессы другой команды. Как применить DDD?
databasedesign - 76
Существующее приложение в AWS замедляется в пики трафика, но каждая команда винит свой компонент. Как вы найдёте архитектурное узкое место до предложения изменений?
trackingarchitecturecomponents - 77
Нагрузка в AWS выполняет SLA, но расходы на облако выросли на 45 процентов за шесть месяцев. Как вы сократите затраты без регрессии производительности?
performance - 78
Команда создаёт API обработки изображений с непредсказуемыми всплесками, задачами от двух секунд до двадцати минут и небольшой операционной командой. Вы выберете serverless или контейнеры?
containersapiconcurrency - 79
Как вы поэтапно перенесёте приносящее выручку on-premises приложение в AWS, если бизнес не принимает одномоментное переключение?
migrationscloud-migration - 80
Нужно перенести активно используемую PostgreSQL в Amazon RDS с простоем записи менее пяти минут. Какой подход вы обоснуете?
databasepostgres - 81
Модульный монолит стало трудно выпускать, а один домен вызывает большинство инцидентов. Как вы решите, нужно ли и как выделять сервис?
monolithmicroservicesincidents - 82
Спроектируйте интеграцию между сервисом заказов в AWS и on-premises ERP, которая разрешает входящие соединения только по частной сети и имеет ночные окна обслуживания.
design - 83
Критичный API службы доставки имеет нестабильную задержку, дублирующие ответы и иногда недоступен два часа. Как вы защитите приложение и сохраните обработку заказов?
procurementapilatency - 84
Стейкхолдер просит active-active развёртывание в AWS и Azure только ради снижения зависимости от поставщика. Как вы оцените запрос?
decision-makingcommunicationdeployment - 85
Команде нужна проверка личности клиентов через четыре месяца. Как вы решите, разрабатывать её самостоятельно или купить управляемое решение поставщика?
procurement - 86
Несколько команд потребляют Kafka-события заказов, и вам нужно добавить новую модель исполнения без поломки старых consumers. Как вы измените контракт события?
kafka - 87
Правило EventBridge может доставить событие подтверждённого платежа больше одного раза. Как вы предотвратите повторное исполнение заказа?
- 88
Product manager хочет мгновенно показывать остатки во всех регионах, но checkout не должен продавать дефицитный товар сверх наличия. Какую модель согласованности вы предложите?
consistencycloud-regions - 89
Профиль клиента ведётся в одном сервисе, но должен обновлять CRM, биллинг и поддержку за десять минут даже при частичных сбоях. Как спроектировать синхронизацию?
system-designdesign - 90
Публичный REST API должен изменить представление клиента, а мобильные клиенты могут оставаться старыми целый год. Как вы версионируете и развернёте изменение?
rest - 91
Как вы ограничите частоту запросов партнёрского API, если у каждого клиента свой контракт, а дорогие GraphQL-запросы могут стоить намного больше простых REST-вызовов?
restgraphqlqueries - 92
Какой дизайн наблюдаемости в Datadog вы потребуете до запуска нового checkout-сервиса в Kubernetes?
kubernetesobservabilitymonitoring - 93
Как вы организуете Terraform и ArgoCD для трёх сред Kubernetes, чтобы избежать дрейфа конфигурации и небезопасного продвижения в production?
kubernetesterraformconfig - 94
Вас просят сравнить managed Kafka с новым serverless-сервисом событий через proof of concept. Что сделает оценку убедительной?
kafkaserverlessdecision-making - 95
Бизнес-стейкхолдеры просят новый клиентский портал, но дают только функциональные требования. Как вы превратите отсутствующие нефункциональные требования в архитектурную основу?
stakeholder-managementarchitecturecommunication - 96
Две команды спорят о REST и gRPC для внутреннего сервиса, чувствительного к задержке. Как вы проведёте и задокументируете решение?
restgrpclatency - 97
Европейский клиент требует хранить персональные данные в ЕС, но глобальной поддержке всё ещё нужно диагностировать сервис. Как вы построите решение?
discovery - 98
Облачные пользователи должны запускать действия на оборудовании внутри заводской сети с нестабильной связью, причём повторные или устаревшие команды опасны. Как спроектировать путь команд?
design - 99
Вы получаете дорогое и нестабильное приложение и два квартала на улучшение без остановки разработки функций. Какую практическую архитектурную дорожную карту вы предложите?
roadmaparchitectureownership - 100
Регулируемые клиенты требуют запускать data plane вашего SaaS в собственных AWS-аккаунтах, а команда управляет единым control plane. Как избежать уникального деплоя для каждого клиента?
deploymentcloudcloud-models