Контракт Scheduler с методами Queue и Status
Определите queued → running → done/failed, уникальность ID, владение request и политику переполнения очереди. Status должен возвращать согласованный снимок и отличать неизвестный ID.
Читать ответПодготовка к интервью
889 вопросов по System Design
Что проверяют на интервью
В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Каталог
Определите queued → running → done/failed, уникальность ID, владение request и политику переполнения очереди. Status должен возвращать согласованный снимок и отличать неизвестный ID.
Читать ответДля подписок нужна модель связей «пользователь — объект подписки», уникальность и удобный поиск в обе стороны. Хранилище выбирают по масштабу fan-out и характеру изменений.
Читать ответПередавайте типизированную запись с ID задачи, исходными данными и необходимыми метаданными. Результат обогащения должен сохранять тот же ID и явный статус ошибки.
Читать ответНужен событийный поток изменений остатков, индекс подписок и ограниченная доставка уведомлений. Уведомлять следует о значимом появлении товара, с дедупликацией и лимитами на пользователя.
Читать ответНачните с оценки объёма данных, конкуренции и возможности последующего изменения схемы. Число шардов выбирают по измерениям, а не по универсальной формуле.
Читать ответSoft hold временно уменьшает доступность по правилам резерва, но финальное подтверждение должно атомарно проверить остаток и действительность удержания. Просроченный резерв нельзя считать гарантией.
Читать ответAPI бронирования должно разделять поиск, временный резерв, подтверждение и отмену. Повторные команды обязаны учитывать идемпотентность и актуальное состояние места.
Читать ответВыделенный collector читает results и атомарно обновляет общее хранилище задач. Status читает снимок из того же хранилища, а не пытается забрать событие из канала.
Читать ответПри перезапуске теряются задания, живущие только в памяти. Для надёжной отправки нужны устойчивая очередь или outbox, graceful shutdown и повторная обработка.
Читать ответРазделите HTTP-слой, сценарий приложения, адаптер внешнего API и репозиторий БД. Внешний сетевой вызов не стоит выполнять под длительной транзакцией с блокировками.
Читать ответОдна запись в Redis сама по себе не появляется в других дата-центрах. Нужна явно настроенная репликация Redis либо отдельная доставка событий и обновление локальных хранилищ.
Читать ответДля бронирования важны отсутствие двойной продажи, надёжность оплаты, задержка, доступность на пиках и восстановление после сбоев. Требования нужно выражать проверяемыми показателями.
Читать ответ