Подготовка к интервью

Вопросы по System Design на собеседовании

889 вопросов по System Design

889 вопросов 1634 компании 353 технологии

Что проверяют на интервью

Как устроена подборка

В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.

Каталог

Результаты поиска

Найдено: 889
System Design

Чем микросервис отличается от модульного монолита? Каковы их преимущества и недостатки?

Микросервисы развертываются и взаимодействуют как отдельные сервисы, модульный монолит — одно приложение с внутренними границами модулей. Главное различие — распределённость и независимость жизненного цикла.

Читать ответ
System Design

Как организовать предоставление информации о том, кто и когда входил в систему и сколько времени провёл в сессии?

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

Читать ответ
System Design

Опишите паттерн распределённых транзакций Saga: оркестрация против хореографии, а также принципы проектирования компенсирующих транзакций.

Saga — последовательность локальных транзакций с компенсациями вместо общей ACID-транзакции. Оркестратор управляет шагами явно; при хореографии участники реагируют на события друг друга.

Читать ответ
System Design

Спроектируйте высоконагруженную систему QR Pay для ресторана: касса печатает QR-код со счётом, пользователь открывает страницу, видит итоговую сумму и переходит на платёжный шлюз; после успешной оплаты заказ должен закрыться. Ожидается около миллиона запросов в час. Опишите сервисы, последовательность вызовов, технологии, безопасность и масштабирование.

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

Читать ответ
System Design

Как организовать работу, если внешняя интеграция разрешает только 1 запрос в секунду, а к вам приходят 10 запросов?

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

Читать ответ
System Design

Как обработать Foreign Key violation в денормализованной таблице consumer-а, если связанные события приходят из Kafka в неправильном порядке?

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

Читать ответ
System Design

Какой смысл использовать API Gateway, если у нас только один сервис?

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

Читать ответ
System Design

Как обеспечить отдельное отображение комиссии в истории операций, сохранив корректность и атомарность перевода?

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

Читать ответ
System Design

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

Ограничьте отправку повторяющихся ошибок до SDK-транспорта, используйте bounded-очередь и отправляйте агрегированную частоту отдельно. Группировка событий по fingerprint сама по себе не уменьшает их число.

Читать ответ
System Design

Каковы требования к хранению истории, порядку сообщений, поиску, шифрованию, доступности, региону размещения и удалению сообщений?

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

Читать ответ
System Design

Если Redis с кэшированным токеном внешнего Auth Service недоступен, как избежать деградации, при которой каждый запрос заново авторизуется?

Используйте ограниченный локальный кеш ещё действующего токена и singleflight для его обновления, чтобы запросы не штормовали Auth Service. Истёкший или недопустимый токен нельзя принимать ради доступности.

Читать ответ