В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Поставьте перед users-api балансировщик с единым адресом, на который будет обращаться webApp. Он выбирает доступную реплику по round-robin, least-connections или другому алгоритму.
Каждый единственный экземпляр — точка отказа, а разделение по сети само по себе не даёт масштабируемости. Нужны резервирование, балансировка и устранение локального состояния users-api.
Разделите систему на адаптеры источников, очередь обработки, нормализацию и API единого каталога. Каждый адаптер преобразует особенности площадки в общий контракт объявления.
CI проверяет код и собирает версионированный артефакт, CD продвигает этот же артефакт через окружения. Production-развёртывание включает проверки готовности, наблюдение и возможность отката.
Метрики собирает система мониторинга, трафик распределяет балансировщик, а неработающие экземпляры исключаются по health-check. Масштабирование выполняет отдельный контроллер по выбранным сигналам.
Создайте upload session с владельцем, общим размером и manifest частей. Каждый chunk имеет номер, размер и checksum; его можно загрузить повторно и независимо от порядка остальных.
Разделите управление конференциями, live-поток и обработку записей. Видео загружают частями напрямую в object storage, затем очередь запускает workers для проверки, watermark и перекодирования.
60 млн пользователей по 15 сообщений — 900 млн сообщений в сутки, около 10,4 тыс./с в среднем. Нужны региональные gateways, маршрутизация чатов, устойчивый журнал и отдельное хранение медиа.
По закону Литтла среднее число запросов в обработке — 1000 × 0,05 = 50. Но это не готовый размер пула БД: нужны время удержания соединения и число обращений к БД.
Ограничьте время попытки и исключайте нездоровый экземпляр из выбора. Безопасный запрос можно повторить на другом инстансе в пределах общего deadline, но гарантировать успех при любом отказе нельзя.
Высокая нагрузка определяется соотношением запросов, объёма данных и ресурсов при заданных SLO, а не универсальным числом RPS. Система справляется, если сохраняет нужные задержки и корректность.
Храните уведомление как устойчивое задание с временем отправки, статусом и уникальным ID. Планировщики выбирают наступившие задания порциями, а очередь и workers выполняют доставку.