Как обозначить связи на схеме backend-сервиса
Покажите клиент → API → БД для приёма и статуса, API/outbox → очередь → worker для обработки и worker → БД для результата. Подпишите назначение и характер каждого обмена.
Читать ответПодготовка к интервью
889 вопросов по System Design
Что проверяют на интервью
В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Каталог
Покажите клиент → API → БД для приёма и статуса, API/outbox → очередь → worker для обработки и worker → БД для результата. Подпишите назначение и характер каждого обмена.
Читать ответДля 300 тысяч хостов ключевы архитектура управления, ограничение параллелизма и безопасный rollout, а не один язык. Нужны инвентарь, очереди, региональные исполнители и подтверждение результата.
Читать ответПри миллионе URL нельзя создавать миллион одновременных задач и держать все ответы в памяти. Нужны потоковый ввод, ограниченная очередь и фиксированный пул обработчиков.
Читать ответРезервируйте слот атомарно в общей БД, а не локальной блокировкой одного backend-процесса. Победителя определяет условное обновление или уникальное ограничение.
Читать ответСформируйте устойчивый ключ операции и атомарно создавайте запись запуска с уникальным ограничением. Все десять запросов должны получить один job ID или его уже готовый результат.
Читать ответМодель можно запускать в контейнере вместе с сервисом инференса, но контейнеризация сама по себе не решает масштабирование, управление весами и требования к GPU.
Читать ответРазделите метаданные и права в БД, бинарные объекты в object storage, а совместное редактирование текста — в отдельный сервис операций и синхронизации.
Читать ответДесять worker-ов должны атомарно распределять записи outbox; иначе они могут одновременно публиковать одно событие. Параллелизм также усложняет сохранение порядка.
Читать ответПодтверждайте сообщение или фиксируйте offset только после устойчивой записи результата. Повторная доставка должна быть безопасной благодаря идемпотентности или дедупликации.
Читать ответИспользуйте Transactional Outbox: сущность и запись о событии сохраняются в одной транзакции БД, а отдельный процесс доставляет событие в брокер с повторами.
Читать ответСохраняйте запланированную SMS в БД с временем отправки и статусом. Планировщик выбирает наступившие задания, а отдельный worker отправляет их через провайдера.
Читать ответИспользуйте асинхронный Redis-клиент, короткий бюджет ожидания и ограниченную конкурентность. Cache miss и недоступность кеша — разные состояния, а fallback должен защищать основную систему от перегрузки.
Читать ответ