В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Жизненный цикл заказа удобно моделировать конечным автоматом: состояния, допустимые переходы, условия и эффекты. Наличие состояний само по себе не делает архитектуру event-driven.
Outbox атомарно сохраняет бизнес-изменение и запись о будущем событии в одной БД-транзакции. Отправка в брокер выполняется отдельно; паттерн не делает commit БД и сетевую отправку одной атомарной операцией.
CQRS разделяет модели и пути изменения состояния и чтения данных. Команды выражают намерение изменить систему, запросы возвращают представление; отдельные базы и event sourcing не обязательны.
Клиент создаёт задачу через API, worker получает её из очереди, строит файл и сохраняет результат. API отдаёт статус и контролируемую ссылку на скачивание только владельцу.
Idempotent Consumer делает повторную обработку события безопасной. Для параллельных копий недостаточно сначала проверить наличие ID: уникальная отметка обработки и бизнес-изменение должны быть атомарны.
Синхронный вызов выбирают, когда ответ нужен прямо сейчас и допустима зависимость от доступности сервиса. Брокер полезен для отложенной обработки, сглаживания пиков и доставки событий нескольким потребителям.
Сообщение помещают в очередь задержки без consumers, задают message TTL и DLX на рабочий exchange. После истечения TTL оно направляется в рабочую очередь, где его получает обработчик.
Пессимистическая блокировка заранее ограничивает конкурирующие изменения, оптимистическая проверяет версию при записи. Для дефицитных слотов важен атомарный запрет двойного бронирования, независимо от выбранного подхода.
Разделите диалог, поиск по утверждённой базе знаний, доступ к банковским данным и передачу оператору. Модель не должна сама выдавать полномочия или выполнять финансовые действия по одному текстовому запросу.
Базу знаний строят из версионируемых источников с владельцами, датами действия и областью применимости. Региональные исключения нужно хранить явно и выбирать по контексту, а не смешивать в один текст.
Bulkhead изолирует ресурсы разных направлений нагрузки. Отдельные пулы соединений, workers и очереди не дают зависшему внешнему сервису занять все ресурсы приложения и остановить остальные функции.