Подготовка к интервью
889 вопросов по System Design
Что проверяют на интервью
В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Каталог
Проверьте право блокировать продавца и идемпотентно создайте запись с уникальным seller_id. Повторная блокировка не должна создавать дубликаты или терять аудит.
Читать ответНормального фиксированного числа микросервисов в контуре нет. Их количество определяется границами ответственности, командой и эксплуатационной ценой.
Читать ответДубликат заявки может быть критичен, если создаёт повторный выезд, оплату или конфликт статусов. Повтор технического запроса и новое обращение жителя нужно различать.
Читать ответКонтракты могут связываться синхронными API, общими событиями и идентификаторами бизнес-сущностей. Важно отличать необходимую связь от зависимости от внутренних моделей.
Читать ответСобытие сначала сохраняют устойчиво, затем отправляют с подтверждением и повторяют после сбоев. Получатель должен безопасно обрабатывать дубликаты: сеть не даёт exactly-once сама по себе.
Читать ответТипичные сбои бронирования — конкуренция за место, истечение резерва, неопределённый результат оплаты и повторные запросы. Нужна явная машина состояний и восстановление.
Читать ответСоздайте ограниченный jobs-канал, запустите ровно N workers и собирайте результаты отдельным потребителем. Закройте results только после завершения всех workers.
Читать ответОпишите PostgreSQL как источник истины и Redis как кэш, если именно так было в проекте. Важны срок жизни, инвалидирование и безопасное поведение при отказе.
Читать ответГраницы сервисов определяют бизнес-ответственностью и владением данными, а взаимодействия — явными API или событиями. Важно избегать скрытой связи через общую схему БД.
Читать ответСервисы выделяют по самостоятельной ответственности, владению данными и потребности в независимом развитии или масштабировании, а не ради заданного количества.
Читать ответЕсть классическая слоистая архитектура, Clean Architecture и Hexagonal; DDD — подход к моделированию предметной области, а не просто ещё один набор слоёв.
Читать ответПроверяйте допустимость запроса до постановки, чтобы не тратить очередь и ресурсы на заведомо некорректную работу. Worker повторно проверяет условия, которые могли измениться.
Читать ответ