В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Некоторые конфигурации БД способны на 100 тысяч записей в секунду, но гарантировать это без условий нельзя. Решают размер событий, индексы, durability, батчи, репликация и оборудование.
Transactional outbox сохраняет бизнес-изменение и запись будущего события в одной транзакции БД. Отдельный relay публикует outbox в брокер после commit.
Saga разбивает общий бизнес-процесс на локальные транзакции сервисов. При ошибке выполняются предусмотренные компенсации, а не общий rollback всех баз данных.
Качество интеграции оценивают по задержке, пропускной способности, доступности, надёжности доставки, корректности данных и совместимости контрактов. Нужны измеримые требования, а не только «работает».
Последнюю позицию водителя и историю маршрута лучше разделить. Для поиска ближайших нужен геоиндекс, для истории — хранилище последовательных событий с ограниченным сроком хранения.
Kafka позволяет развести приём аудита и обработку, но нужны партиционирование, пакетная запись и хранилище под запросы и срок хранения. Сотни тысяч событий требуют расчёта объёма.
По одной цифре 100 тысяч insert/sec выбрать БД нельзя. Нужны размер записи, профиль чтения, индексы, требования к транзакциям, допустимая потеря данных и целевая p99 latency.
Для оперативной статистики подходят счётчики запросов по сервису и результату. Для точного аудита нужен отдельный устойчивый журнал событий, а не только мониторинговые метрики.
В Redis sorted set идентификатор задачи можно хранить как member, а время запуска — как score. Готовые задачи выбирают по score не больше текущего времени.
Проверьте retries клиента и сервисов, повторную доставку событий и гонку создания без уникального бизнес-ключа. Сначала остановите новые дубли и найдите, где одна заявка превратилась в три эффекта.
Критичный результат запроса возвращается синхронно, а независимые последующие действия выполняются асинхронно. Границу определяет требуемая согласованность, а не желание использовать больше технологий.
По числу 100 тысяч активных пользователей количество Kafka partition определить нельзя. Нужны частота платежей, событий на операцию, размер сообщений, скорость consumer и пиковая нагрузка.
