Подготовка к интервью
889 вопросов по System Design
Что проверяют на интервью
В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Каталог
System design начинается с требований, нагрузки и инвариантов, затем определяет API, данные и компоненты. Основные темы — масштабирование, отказоустойчивость, консистентность и наблюдаемость.
Читать ответПример: после подтверждённого зачисления денег нужно уведомить клиента. Изменение статуса зачисления и событие PaymentCompleted сохраняются в одной транзакции БД через outbox.
Читать ответIstio подходит для единых сетевых политик между сервисами: mTLS, авторизации, управления трафиком и наблюдаемости. Это service mesh, а не замена бизнес-логике приложения.
Читать ответИспользуйте expand–migrate–contract: сначала добавьте dep_name, обеспечьте синхронизацию новых записей, выполните backfill порциями, проверьте данные и только потом переключайте чтение.
Читать ответДа, это может быть основой at-least-once, если ответ означает устойчивое завершение операции. Но сбой после внешнего успеха и до commit приведёт к повторной обработке сообщения.
Читать ответВнутри сервиса применяют слоистую, hexagonal/ports-and-adapters, clean architecture или модульную организацию по бизнес-возможностям. Это способы управлять зависимостями и границами, а не обязательные шаблоны папок.
Читать ответНачните с сущностей, связей, бизнес-инвариантов и профиля запросов. Затем проектируйте ключи, ограничения, индексы и транзакционные границы под реальные сценарии.
Читать ответKafka принимает события планирования, обработчик сохраняет job ID в Redis sorted set со временем отправки в score, а scheduler выбирает наступившие задания и передаёт исполнителям.
Читать ответ30 000 сообщений в минуту — это в среднем 500 в секунду. Число партиций выбирают по измеренной производительности одной партиции/consumer, пикам и требуемому параллелизму.
Читать ответCommit после REST-ответа не делает внешний вызов и локальное изменение атомарными. Внешняя операция могла завершиться, а локальная транзакция — упасть; timeout также не доказывает отказ.
Читать ответMission-critical система критична для основной деятельности: её отказ останавливает существенный процесс или создаёт недопустимые потери. Это не обязательно система, опасная для жизни.
Читать ответЗадайте общий deadline и передавайте остаток бюджета всем этапам: очередям, БД и сетевым вызовам. Отдельный timeout на каждом шаге не гарантирует общий предел десять секунд.
Читать ответ