В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Планировщик порциями создаёт уникальные задания и outbox в БД, publisher отправляет их в Kafka, consumer вызывает SMS-провайдера. Ключ кредита, даты и типа напоминания подавляет повторное планирование.
Kafka позволяет отделить приём от обработки и сгладить пики долговечной очередью. Масштабирование синхронного API не создаёт такую гарантию и может усилить давление на ограниченную БД.
3000 сообщений в минуту — в среднем 50 в секунду, но этого недостаточно для выбора partition. Нужны размер сообщения, стоимость обработки, пиковый поток, порядок и требуемый запас мощности.
Kafka полезна для отделения приёма от обработки, сглаживания пиков и независимых подписчиков. Масштабирование синхронных экземпляров не устраняет медленную зависимость и не создаёт долговечную очередь само по себе.
Сначала найдите узкое место и защитите систему от перегрузки: ограничьте входящий поток и очереди, затем оптимизируйте или масштабируйте ограничивающий ресурс. Больше экземпляров не всегда помогает.
Самописный брокер может быть оправдан узкой семантикой или историческими ограничениями, но требует самостоятельно обеспечивать надёжность и эксплуатацию. Конкретную причину выбора нужно подтвердить контекстом.
Используйте устойчивую операцию со статусами, идемпотентным списанием и одним ключом обращения к провайдеру. Неизвестный результат сначала сверяют, а не сразу списывают или возвращают деньги повторно.
REST-вызов внутри consumer связывает скорость Kafka-обработки с доступностью внешнего сервиса. Медленный вызов блокирует обработку partition, накапливает lag и может вызвать rebalance при превышении poll-интервала.
Используйте изоляцию ресурсов по провайдерам: отдельные лимиты параллелизма и очередей, timeout, circuit breaker и ограниченные retries. Медленная зависимость не должна занимать все workers и соединения.
Снижают зависимость от синхронного Auth Service: при подходящей модели подписанные access tokens проверяют локально, а сервис авторизации делают отказоустойчивым. Отказ проверки не должен автоматически разрешать доступ.
Бизнес-значимые расчёты и итоговые денежные значения должны определяться backend по единому правилу. Frontend может форматировать результат и показывать предварительную оценку, не становясь источником истины.
Для единственной копии отложенных уведомлений вытеснение недопустимо: выбирают noeviction и обрабатывают отказ записи при нехватке памяти. Надёжнее хранить источник истины в долговечном хранилище.
