В этой подборке вопросы сгруппированы по формату «System Design», чтобы подготовку можно было вести от базовых тем к практическим задачам. В подборке чаще встречаются темы: backend, api, database.
Постройте каскад: надёжные правила для однозначных случаев, ML для массовых, LLM только для сложных и человек для низкой уверенности или высокого риска. Каждый этап должен уметь отказаться от решения.
Разделите приём событий, выбор получателей/каналов, шаблоны и доставку. Запрос бизнеса фиксируется надёжно, а отправка выполняется асинхронно через очереди и адаптеры провайдеров.
Вердикт должен содержать статус, коды причин, версию правил, время и источник решения. Пересмотр оформляйте новой версией с историей, а не бесследной заменой.
Назначайте уведомлению стабильный ключ по бизнес-событию, получателю, каналу и типу сообщения. Уникальное ограничение и сохранённое состояние доставки защищают от повторной обработки.
Исходники превращаются в версионированный контейнерный образ, CI проверяет его и публикует в registry. Kubernetes разворачивает реплики, а Service и входной маршрутизатор доставляют им трафик.
Начните с рекомендателя на основе навыков, пройденных тем и сложности, а затем сравнивайте его с обучаемой моделью. Цель — прогресс ученика, а не только клики по заданиям.
Добавьте стабильный code, безопасное сообщение, ошибки по полям и request_id. HTTP-статус должен отражать класс проблемы, а технические подробности оставаться на сервере.
Нужны сервис инвентаризации, управление группами, оркестратор заданий и приём статусов агентов. Панель создаёт декларативную задачу, а не исполняет произвольные команды от имени браузера.
Разделите загрузку, асинхронное перекодирование и выдачу через CDN. При 50 млн зрителей и пяти видео в день получается 250 млн просмотров в сутки — около 2,9 тыс. стартов в секунду в среднем.
Разделите заголовок заказа и его позиции: orders хранит покупателя и дату, order_items — товары, количество и цену покупки. Сейчас строка Order смешивает оба уровня.
Если это независимые базы без согласованного распределения данных, разные реплики users-api будут видеть разное состояние. Обычная балансировка запросов начнёт возвращать противоречивые результаты.
Gateway определяет целевой сервис по маршруту, получает из discovery список готовых экземпляров и выбирает один балансировщиком. Discovery сообщает адреса, но сам не обязан распределять запросы.
