DEV Community: NowInterview

System Design: проектируем сервис заказа такси

NowInterview — Thu, 16 Apr 2026 13:51:55 +0000

Перевод на русский язык статьи Design Uber

Видеоразбор этой задачи на русском языке можно посмотреть здесь - https://youtu.be/R9B90ewl9EY

Постановка задачи

🚗 Что такое Uber?

Uber - платформа для заказа такси, которая связывает пассажиров и
водителей. Она позволяет пассажирам заказать такси со смартфона,
подбирая ближайшего водителя неподалеку, который доставит их из
места нахождения в желаемое место назначения.

Функциональные требования

В начале интервью определите функциональные и нефункциональные
требования. Для пользовательских приложений функциональные
требования - это формулировки вида “Пользователь может…”, а
нефункциональные - это характеристики системы вида “Система
должна…”.

Приоритизируйте 3-4 ключевых функциональных требования. Все
остальные требования показывают, что вы обладаете продуктовым
мышлением, но явно обозначьте это “за рамками задачи”, чтобы
интервьюер понимал, что эти пункты не входят в дизайн. Уточните,
не хочет ли интервьюер увеличить/уменьшить приоритет какого-то
требования. Выбор только 3-4 требований помогает оставаться
сфокусированным и уложиться во временные рамки интервью.

Основные требования

Пассажиры могут указать начальное и конечное местоположение и получить стоимость поездки.
Пассажиры могут заказать поездку.
После запроса пассажира система подбирает доступного водителя поблизости.
Водители могут принять/отклонить запрос.

За рамками задачи

Пассажиры могут оценивать поездку после завершения, а водители могут оценивать пассажиров.
Пассажиры могут заранее планировать поездки.
Пассажиры могут выбирать категории поездок (например, Эконом, Комфорт).

Нефункциональные требования

Основные требования

Система должна обеспечивать высокую скорость подбора водителя (< 1 минуты до принятия запроса или отказа).
Система должна обеспечивать сильную согласованность при подборе водителя, чтобы одному водителю не назначались несколько поездок одновременно.
Система должна выдерживать высокую нагрузку, особенно в пиковые периоды или во время популярных событий (100k запросов в секунду из одной локации).
Масштабирование - 100 млн DAU, 15 млн поездок в день

За рамками задачи

Система должна обеспечивать безопасность и приватность данных пользователей и водителей, соблюдая требования государственных регуляторов.
Система должна быть отказоустойчивой, с механизмом аварийного восстановления.
Система должна иметь мониторинг, логирование и уведомления для быстрого обнаружения проблем.

На доске это может выглядеть примерно так:

Описание требований за рамками задачи показывает продуктовое
мышление и дает интервьюеру возможность переопределить
приоритеты. Но это все же необязательная вещь, если
дополнительные идеи не приходят в голову сразу, не тратьте время
и двигайтесь дальше.

Подготовка

Планирование подхода

Прежде чем переходить к проектированию системы, важно на секунду остановиться и продумать стратегию. К счастью, для “продуктовых” задач план обычно простой: последовательно собирать дизайн, проходя по функциональным требованиям одно за другим. Так вы сохраните фокус и не утонете в деталях.

Когда функциональные требования удовлетворены, используйте нефункциональные требования, чтобы определить направления для погружения в детали, где это необходимо.

Проектирование API

Начнем с определения основных сущностей, это поможет спроектировать API. Пока не обязательно знать каждое поле или колонку, но если у вас уже есть представление о том, что там будет - можно это записать.

Для основных функциональных требований понадобятся следующие сущности:

Rider (Пассажир): пользователь, который запрашивает поездку. Содержит личные данные, контактную информацию, способы оплаты и т. п.
Driver (Водитель): пользователь, зарегистрированный как водитель. Содержит личные данные, информацию о машине (марка, модель, год), предпочтения и статус доступности.
Fare (оценка стоимости): оценка стоимости поездки. Содержит точки старта и назначения, цену и ожидаемое время поездки. Эту информацию также можно просто хранить в сущности Ride, но пока мы оставим ее отдельно (здесь нет правильного или неправильного ответа).
Ride (Поездка): запись о поездке от момента запроса стоимости до завершения. Содержит информацию о пассажире и водителе, машине, состоянии поездки, маршруте, конечной стоимости, а также временные метки посадки и высадки.
Location (Местоположение): актуальная позиция водителей с координатами и временем обновления. Эта сущность является ключевой для подбора водителя и отслеживания поездки.

В реальном интервью достаточно короткого списка как выше - главное проговорить сущности и убедиться, что вы и интервьюер одинаково их понимаете.

API для получения оценки стоимости достаточно простой. Определим POST эндпоинт, который принимает текущую локацию и пункт назначения, и возвращает объект Fare с оценкой цены и времени поездки. Мы используем POST, потому что создаем новую запись о поездке в базе данных.

POST /fares -> Fare
Body: {
  pickupLocation,
  destinationLocation
}

Эндпоинт заказа поездки: после того как пользователь увидел оценку, он подтверждает поездку. Этот эндпоинт инициирует процесс подбора водителя и создает новую запись Ride.

POST /rides -> Ride
Body: {
  fareId
}

На этом этапе мы сопоставляем пассажира с доступным водителем поблизости. Этот процесс происходит на стороне сервера, поэтому отдельный эндпоинт не нужен.

Эндпоинт обновления местоположения водителя: чтобы подобрать водителя нужно знать, где он находится в данный момент. Этот эндпоинт вызывается клиентом водителя регулярно, чтобы держать его местоположение актуальным, обновляя базу данных.

POST /drivers/location -> Success/Error
Body: {
  lat, long
}

// заметим, что driverId берется из сессии или auth-токена и не 
// передается в теле или параметрах пути запроса

Всегда учитывайте безопасность API. Часто кандидаты передают в
тело запроса userId, метки времени или даже оценку стоимости.
Это красный флаг для интервьюера: любые данные от клиента можно
подделать. Пользовательские данные должны приходить из сессии или
auth-токена, метки времени должны генерироваться на сервере, а
оценку стоимости нужно получать из базы данных.

Эндпоинт принятия заказа: водитель принимает заказ, после чего система обновляет статус поездки и возвращает координаты точки посадки.

PATCH /rides/:rideId -> Ride
Body: {
  accept/reject
}

Объект Ride должен содержать информацию о точках посадки и назначения, чтобы
клиент водителя мог отобразить ее в интерфейсе.

Высокоуровневый дизайн

1. Пассажиры могут указать начальное и конечное местоположение и получить стоимость поездки

Первое что делает пассажир - отправляет запрос на стоимость поездки, указав точку назначения.

Соберем минимальный набор компонентов для расчета стоимости, добавив первый сервис - сервис поездок:

Основные компоненты для оценки стоимости:

Клиент пассажира: мобильное приложение на смартфоне пассажира, которое взаимодействует с бэкендом.
API-шлюз: точка входа для запросов от клиентов, отвечает за маршрутизацию, аутентификацию, ограничение запросов и т.д.
Сервис поездок: управляет состоянием поездки, начиная с расчета стоимости. Он взаимодействует со сторонними картографическими API для определения расстояния и времени в пути между точками и применяет модель ценообразования компании для расчета стоимости проезда. Для целей данного интервью мы абстрагируемся от деталей этого алгоритма.
Сторонний сервис Maps API: сторонний картографический API сервис (например, Google Maps) для расчета расстояния и времени в пути.
База данных: сохраняет объекты Fare.

Рассмотрим как эти компоненты взаимодействуют когда пассажир запрашивает стоимость поездки:

Пользователь вводит начальное и конечное местоположение и отправляет POST запрос на /fares.
API-шлюз принимает запрос, проверяет аутентификацию и ограничения, и маршрутизирует его в сервис поездок.
Сервис поездок запрашивает картографический API для получения расстояния и времени и вычисляет стоимость поездки.
Сервис поездок сохраняет объект Fare в базе данных.
Fare возвращается через API-шлюз, и пользователь решает, делать ли заказ.

2. Пассажиры могут заказать поездку

После получения стоимости и времени поездки пользователь заказывает поездку. Это действие просто расширяет существующий дизайн - мы добавляем таблицу rides.

Когда заказ на поездку приходит мы обрабатываем его следующим образом:

Пользователь заказывает поездку, отправляя POST запрос с fareId.
API-шлюз после проверок отправляет запрос в сервис поездок.
Сервис поездок создает запись Ride, ссылаясь на оценку стоимости Fare, и устанавливает для поездки статус requested.
Затем запускается процесс подбора водителя (см. ниже).

3. После запроса пассажира система подбирает доступного водителя поблизости

Для реализации механизма подбора водителя в наш дизайн необходимо добавить несколько новых компонентов:

Клиент водителя: принимает запросы на поездки и отправляет обновления локации в сервис локаций.
Сервис локаций: принимает обновления локаций, сохраняет их в базу данных.
Сервис подбора водителя: обрабатывает запросы на новые поездки и выбирает оптимального водителя (по близости, рейтингу и другим факторам).

Водители постоянно (например, раз в 5 секунд) отправляют свое текущее местоположение в сервис локаций, и мы обновляем базу данных с указанием их последнего местоположения по широте и долготе. Сервис подбора водителей использует эти данные когда приходит запрос на новую поездку для поиска оптимального соответствия.

4. Водители могут принять/отклонить запрос

Как только водитель будет сопоставлен с пассажиром, он сможет принять запрос на поездку. Добавим в дизайн новый компонент:

Сервис нотификаций: Отвечает за отправку уведомлений в режиме реального времени водителям, когда им подобран новый запрос на поездку. Уведомления отправляются через APN (Apple Push Notification) и FCM (Firebase Cloud Messaging) для устройств iOS и Android соответственно.

Последовательность событий при этом следующая:

Сервис подбора водителя формирует список подходящих водителей и отправляет уведомление первому в списке через APN/FCM.
Водитель открывает приложение и принимает запрос, отправляя PATCH запрос с rideId. Если водитель отклоняет запрос, сервис уведомляет следующего.
API Gateway маршрутизирует запрос в сервис поездок.
Сервис поездок обновляет статус поездки на accepted, устанавливает для поездки driverId и возвращает водителю координаты точки посадки.
Водитель использует GPS своего клиента, чтобы построить маршрут до точки посадки.

Интервьюер ожидает push‑уведомления водителям? Разбор паттерна
Обновления в реальном времени охватывает опции от
long‑polling до SSE и WebSockets.

Потенциальные погружения в детали

Когда основные функциональные требования закрыты, мы можем перейти к нефункциональным требованиям, углубляя наш дизайн там, где это необходимо.

Насколько глубоко кандидат должен погружаться в детали зависит от > уровня. Для Middle кандидатов нормально, если интервьюер ведет
большую часть обсуждения. Для Senior и Staff+ ожидается больше
инициативы: кандидат сам видит проблемы в дизайне и предлагает
решения.

1. Как обрабатывать частые обновления локаций водителей и эффективный поиск по близости?

Управлять потоком обновлений локаций и выполнять быстрые запросы на поиск по локации сложно, и текущий high-level дизайн с этим не справляется. Есть две основные проблемы:

Высокая частота записей: если у нас около 5 млн водителей и они отправляют локации каждые 5 секунд, это ~1 млн обновлений в секунду. Независимо от того, выберем ли мы что-то вроде DynamoDB или PostgreSQL (оба являются отличным выбором для остальной части системы), они либо не выдержат такую нагрузку, либо их придется масштабировать настолько, что они станут слишком дорогими.
Эффективность запросов: без оптимизаций запросы по координатам (proximity search) требуют полного сканирования таблицы и вычисления расстояния до каждого водителя. Даже с B‑tree индексами это плохо работает для многомерных данных вроде координат.

Что можно сделать, чтобы разобраться с этими проблемами?

Плохое решение: Прямая запись в базу и proximity‑поиск

Подход

Плохое решение - это наш текущий high-level дизайн: записывать каждое обновление локации в базу и выполнять proximity‑поиск по этим сырым данным. Этот подход плохо масштабируется из‑за высокой частоты обновлений и делает proximity‑поиск неэффективными и медленными. Этот метод приведет к перегрузке системы, высокой
задержке и ухудшению пользовательского опыта, что сделает его непригодным для приложения масштаба Uber.

Хорошее решение: Пакетная обработка и специализированная гео‑база

Подход

Вместо записи каждого обновления напрямую в базу мы агрегируем обновления за небольшой интервал времени и записываем их пакетами. Это снижает количество операций записи, а также повышает пропускную способность записи и уменьшает количество конфликтов.

Для поиска ближайших водителей используем специализированную геопространственную базу данных с индексами, например на основе деревьев квадрантов (quadtrees).
Деревья квадрантов особенно хорошо подходят для двумерных пространственных данных, таких как географические координаты, поскольку они рекурсивно делят пространство на квадранты, что значительно ускоряет proximity‑поиск.

Если использовать PostgreSQL, у него есть расширение
PostGIS, которое позволяет использовать
геопространственные типы и функции без необходимости отдельного хранилища.

Проблемы

Интервал пакетных записей приводит к задержке: данные о локациях становятся слегка устаревшими, а это ведет к ухудшению качества подбора водителей.

Отличное решение: In‑memory гео‑хранилище реального времени

Подход

Мы можем устранить ограничения предыдущих решений, используя in‑memory хранилище вроде Redis, которое поддерживает геопространственные типы и команды. Это позволяет нам обрабатывать обновления местоположения водителей в режиме реального времени и эффективно выполнять proximity-поиск, одновременно минимизируя затраты на хранение за счет автоматического истечения срока действия данных.

Redis использует geohashing для кодирования широты и долготы в единое строковое значение, которое хранится в отсортированных множествах.

Redis предоставляет специализированные команды, такие как
GEOADD и GEOSEARCH, которые эффективно обрабатывают обновления в реальном времени и proximity‑поиск. Команда GEOSEARCH, которая появилась в Redis 6.2, заменяет и расширяет функциональность старых команд GEORADIUS и GEORADIUSBYMEMBER, давая больше гибкости и улучшая производительности.

Пакетная обработка больше не нужна: Redis справляется с большим потоком обновлений в реальном времени. Кроме того, Redis автоматически удаляет данные на основе заданного времени жизни (TTL), что позволяет нам сохранять только самые последние обновления местоположения и избегать ненужных затрат на хранение.

Проблемы

Главная проблема этого подхода - надежность. Поскольку Redis хранит все данные в памяти (in‑memory), возможны потери данных при сбое. Однако эти риски можно смягчить несколькими способами:

Redis persistence: мы можем включить механизмы сохранения Redis, такие как RDB (Redis Database) или AOF (append-only file), чтобы периодически сохранять данные в памяти на диск.
Redis Sentinel: мы можем использовать Redis Sentinel для обеспечения высокой доступности. В случае выхода из строя главного узла Sentinel обеспечивает автоматическое переключение на реплику.

Даже при потере данных ущерб минимален: локации обновляются каждые 5 секунд, и система быстро восстанавливает состояние.

2. Как снизить перегрузку из‑за частых обновлений локаций без потери точности?

Частые обновления локаций перегружают сеть и серверы, что может замедлять работу системы и ухудшать пользовательский опыт. Большинство кандидатов предлагают обновлять локацию водителя каждые 5 секунд или около того. Можем ли мы разумно уменьшить количество обновлений, сохраняя при этом точность?

Отличное решение: Адаптивные интервалы обновлений

Подход

Мы можем решить эту проблему, внедрив адаптивные интервалы обновления локаций, которые динамически регулируют частоту обновления в зависимости от таких факторов как скорость, направление движения, близость к ожидающим запросам на
поездку и статус водителя.

Приложение водителя использует датчики устройства и определенные алгоритмы для определения оптимального интервала. Если водитель стоит или движется медленно - обновления могут отсылаться реже. И наоборот, если водитель движется быстро или часто меняет направление, обновления отправляются чаще.

Проблемы

Основная сложность этого подхода - корректно построить эффективный алгоритм определения оптимальной частоты обновления. Он может потребовать тщательного тестирования в несколько итераций. Но если все сделать правильно, это значительно сократит количество обновлений и повысит эффективность системы.

Не пренебрегайте клиентом, думая о своем дизайне. У многих
кандидатов появляется привычка рисовать маленький прямоугольник
"клиент" и двигаться дальше. Во многих случаях нам нужна логика
на стороне клиента для повышения эффективности и масштабируемости
нашей системы. Как вы видели, мы можем уменьшить количество
обновлений, используя встроенные датчики и алгоритмы для
определения оптимального интервала их отправки. Аналогичным
образом, для сервиса загрузки файлов клиент отвечает за разбитие
на куски и сжатие.

3. Как предотвратить назначение нескольких поездок одному водителю?

Мы определили сильную согласованность при подборе водителя как ключевое нефункциональное требование. Это означает что каждый заказ посылается на рассмотрение только одному водителю, И один водитель в каждый момент времени имеет только один заказ на рассмотрении. У водителя есть 10-15 секунд на принятие/отклонение заказа, после чего система переходит к следующему водителю. Если вы рассматривали задачу проектирования сервиса бронирования билетов, это очень
похоже, поскольку мы гарантируем что билет продается только один раз, и он зарезервирован на определенное время при оформлении заказа.

Плохое решение: Блокировка на уровне приложения и проверка таймаута

Подход

Основная идея заключается в том, что нам нужно заблокировать водителей, чтобы предотвратить одновременную отправку нескольких запросов на поездку одному и тому же водителю. Один из подходов - использовать блокировку на уровне приложения, при которой каждый экземпляр сервиса подбора водителя помечает запрос на поездку как "locked" при его отправке водителю. Затем он запускает таймер на время блокировки. Если водитель не принимает поездку в течение этого периода, сервер снимает блокировку и делает запрос доступным для других водителей.

Проблемы

У этого подхода несколько проблем:

Отсутствие координации: при работе нескольких экземпляров сервиса подбора водителя централизованная координация отсутствует, что приводит к потенциальным состояниям гонки, когда два экземпляра могут одновременно попытаться заблокировать один и тот же запрос на поездку.
Несогласованное состояние блокировки: если один экземпляр устанавливает блокировку и отказывает перед ее снятием (из-за сбоя или проблемы с сетью), другие экземпляры не знают об этом, что может оставить запрос на поездку в заблокированном состоянии на неопределенный срок.
Проблемы масштабирования: по мере увеличения количества экземпляров проблема координации блокировок между ними становится более явной, что приводит к более высокой вероятности ошибок и несогласованностей.

Хорошее решение: Блокировка через статус в базе данных и таймаут

Подход

Чтобы решить проблему координации, мы можем переместить блокировку в базу данных. Это позволяет нам использовать встроенные транзакционные возможности базы данных, чтобы гарантировать, что только один экземпляр может одновременно заблокировать запрос на поездку. Когда мы отправляем запрос водителю, мы обновляем статус этого водителя на "outstanding_request". Если водитель принимает запрос, мы обновляем статус на "accepted", а если отклоняет, мы
обновляем статус на "available". Затем мы можем использовать простой механизм таймаута в сервисе поездок, чтобы гарантировать, что блокировка будет снята, если водитель не ответит в течение 10 секунд.

Проблемы

Хотя мы решили проблему координации, мы по-прежнему сталкиваемся с проблемами, связанными с использованием таймаута в памяти для разблокировки, если водитель не отвечает. Если сервис поездок выйдет из строя или будет перезапущен, таймаут будет потерян, а блокировка останется на неопределенный срок. Это распространенная проблема с таймаутами в памяти, и причина их избегать, когда
это возможно. Одним из решений является создание cron-задания, которое будет периодически запускаться для проверки наличия блокировок с истекшим сроком действия и их снятия. Это будет работать, но добавляет ненужную сложность и задерживает разблокировку запроса на поездку.

Отличное решение: Распределенная блокировка с TTL

Подход

Чтобы решить проблему таймаута, мы можем использовать распределенную блокировку, реализованную с помощью in-memory хранилища, такого как Redis. Когда водителю отправляется запрос на поездку, создается блокировка с уникальным идентификатором (например, driverId) и TTL = 10 секунд. Сервис подбора
водителей пытается получить блокировку driverId в Redis. Если блокировка успешно получена, это означает, что ни один другой экземпляр сервиса не сможет отправить запрос на поездку тому же водителю до тех пор, пока не истечет срок действия блокировки или она не будет снята. Если водитель соглашается на поездку
в течение 10 секунд, сервис подбора водителя обновляет статус поездки на "accepted" в базе данных, и блокировка снимается в Redis. Если водитель не соглашается на поездку, блокировка в Redis немедленно снимается и водитель становится доступным для новых запросов на поездку.

Проблемы

Основная проблема этого подхода - зависимость системы от доступности и производительности Redis. Нам нужны надежные стратегии мониторинга и аварийного переключения, чтобы гарантировать, что система может быстро восстановиться после
сбоев и что блокировки не будут потеряны.

4. Как гарантировать, что запросы поездок не теряются в пиковые периоды?

В периоды пиковой нагрузки система может получать большое количество запросов на поездки, которые мы не сможем обработать и они будут отклонены. Например, это часто происходит во время особых мероприятий или праздников, когда спрос резко вырастает. Нам также необходимо защититься от случаев, когда один из серверов сервиса подбора водителя выходит из строя или перезапускается, что не должно приводить к потере запросов на поездки.

Плохое решение: Без очереди

Подход

Самый простой подход - обрабатывать запросы на поездки по мере их поступления без какой-либо системы очередей (как это сделано в текущем дизайне).

Проблемы

Основная проблема этого подхода заключается в том, что он плохо масштабируется в периоды высокой нагрузки. По мере увеличения количества входящих запросов и перегрузки система начинает отбрасывать запросы, которые не может обработать, что приводит к ухудшению пользовательского опыта. Мы можем горизонтально
масштабировать наш сервис подбора водителей, но при внезапном всплеске спроса мы не сможем масштабироваться достаточно быстро, чтобы полностью предотвратить потерю запросов.

Кроме того, если один из экземпляров сервиса выходит из строя, все запросы на поездки, обрабатываемые этим экземпляром, будут потеряны. Это приведет к тому, что пассажиры будут бесконечно ждать подбора, который так и не случится.

Отличное решение: Очередь и динамическое масштабирование

Подход

Чтобы решить эту проблему, мы можем добавить очередь, куда попадает запрос на поездку. Сервис подбора водителей обрабатывает запросы из очереди в порядке их поступления и может масштабироваться горизонтально в зависимости от размера очереди. Этот подход также позволяет гарантировать, что ни один запрос не будет отброшен или потерян. Мы также можем разделить очереди по географическим регионам для дальнейшего повышения эффективности.

Мы могли бы использовать распределенную очередь сообщений, такую как Kafka, которая позволяет нам подтверждать обработку сообщения только после того, как мы успешно подобрали водителя. Таким образом, если экземпляр сервиса подбора выйдет из строя, запрос на поездку все равно будет находиться в очереди, и его подберет другой
экземпляр. Такой подход гарантирует, что ни один запрос на поездку не будет потерян при сбое.

Проблемы

Основная проблема этого подхода - добавленная сложность. Нам необходимо обеспечить масштабируемость, отказоустойчивость и высокую доступность очереди. Мы можем решить эту проблему, используя managed сервис очередей, такой как Amazon SQS или Kafka, который предоставляет требуемые характеристики "из коробки". Это позволяет нам сосредоточиться на бизнес-логике нашей системы, не
беспокоясь об инфраструктуре.

Еще одна проблема в том, что обработка некоторых запросов может занимать много времени, блокируя другие "более быстрые" запросы. Это распространенная проблема с очередями FIFO, и ее можно решить, используя очередь с приоритетом. Это позволит нам определять приоритетность запросов на основе таких факторов, как
близость водителя, рейтинг водителя, класс поездки и так далее.

5. Что делать, если водитель не отвечает вовремя?

Наша система прекрасно работает, когда водители либо принимают, либо отклоняют заявку на поездку. Но если водитель сделал перерыв и не реагирует на запросы, мы должны гарантировать, что запрос на поездку будет продолжать обрабатываться, перенаправляя запрос следующему водителю.

Процессы которые требуют реакции или действий от человека часто
сигнализируют, что > мы столкнулись с паттерном Многошаговые
процессы. На самом деле, Uber является первоначальным автором
проекта с открытым исходным кодом Cadence, который лег в
основу Temporal - системы надежного исполнения, созданную
специально для таких случаев.

Хорошее решение: Очередь с задержками

Подход

Мы можем реализовать очередь с задержками, чтобы автоматически повторять запросы на поездку со следующим доступным водителем, если текущий водитель не отвечает в течение таймаута. Когда запрос на поездку отправляется водителю, мы одновременно планируем отложенное сообщение в очереди (например, Amazon SQS позволяет добавить сообщение с таймаутом видимости, в нашем случае 10 секунд). Отложенное сообщение содержит сведения о запросе и водителе, с которым первоначально связались. При обработке отложенного сообщения система проверяет, не назначена ли еще поездка. Если это так, запрос автоматически переходит к следующему водителю, одновременно планируя еще одно отложенное сообщение для нового
водителя и так далее.

Проблемы

И опять сложность - основная проблема такого подхода. Если водитель соглашается на поездку, нам необходимо убедиться, что отложенное сообщение обрабатывается корректно и не приводит к неправильному переназначению поездки. Кроме того, этот подход требует тщательной координации между очередью и сервисом подбора водителей, чтобы обеспечить согласованность и избежать состояний гонки.

Отличное решение: Надежное исполнение (durable execution)

Подход

Эти системы обеспечивают встроенную поддержку таймаутов, повторных попыток и управления состоянием таким образом, чтобы выдерживать сбои и перезапуски сервисов. Весь процесс подбора водителя моделируется как workflow, который может обрабатывать сложную бизнес-логику, при этом постоянно сохраняет свое состояние,
поэтому даже в случае сбоя процесс можно возобновить с того места, где он был остановлен.

Например, Temporal workflow может выглядеть так:

Отправляем запрос первому водителю.
Устанавливаем таймаут на 10 секунд.
Если водитель принимает - завершаем workflow.
Если водитель отклоняет или таймаут истекает - автоматически переходим к следующему водителю.
Продолжаем пока водитель не найден или список водителей не исчерпан.

Проблемы

И опять мы добавляем дополнительную сложность, внедряя систему оркестрации workflow. Это требует от инженеров изучения новых концепций и инструментов и добавляет в систему еще один компонент, который необходимо мониторить и обслуживать.

Однако преимущества гарантированного выполнения, встроенной отказоустойчивости и упрощенной бизнес-логики часто перевешивают эти проблемы, особенно для критически важных систем, где отброшенные запросы напрямую влияют на финансовые показатели и удобство пользователей.

6. Как дальше масштабировать систему, снижая задержку и повышая пропускную способность?

Плохое решение: Вертикальное масштабирование

Подход

Самый простой путь - вертикальное масштабирование, при котором мы увеличиваем мощность существующих серверов, добавляя больше CPU, памяти или дисков. Это быстрый и простой способ увеличить емкость, но он имеет ряд ограничений.

Проблемы

Это решение плохое по многим причинам. Во-первых, это дорого и требует простоя для обновления серверов. Во-вторых, мы не сможем вертикально масштабироваться бесконечно. Наконец, это решение не является отказоустойчивым. Если сервер выйдет из строя, вся система выйдет из строя. На интервью обсуждать этот вариант вряд ли стоит, поскольку для системы такого масштаба он непрактичен.

Отличное решение: Гео-шардирование и реплики чтения

Подход

Лучшим подходом является горизонтальное масштабирование путем добавления дополнительных серверов. Мы можем сделать это, разделив наши данные по географическому принципу и используя реплики чтения для повышения пропускной способности чтения. Важно отметить, что это не только позволяет нам масштабироваться, но и снижает задержку за счет уменьшения расстояния между клиентом и сервером. Все компоненты системы: сервисы, очереди сообщений и базы данных можно шардировать географически. Единственный случай, когда нам
понадобится межрегиональное вычисление (например, запрос по нескольким шардам), - это когда мы выполняем proximity-поиск на границе нескольких шардов.

Проблемы

Главная сложность - правильное управление шардированием. Нам необходимо гарантировать, что данные распределяются равномерно по шардам и что система может обрабатывать сбои и выполнять перебалансировку. Мы можем решить это, используя согласованное хеширование для распределения данных по шардам и реализуя стратегию репликации для повышения отказоустойчивости.

Итоговая архитектура нашей системы может выглядеть примерно так:

Что ожидается на каждом уровне?

Хорошо, мы обсудили много всего. Возникает резонный вопрос: "сколько из этого реально ожидается от меня на интервью?" Разберем по уровням.

Middle

Ширина vs глубина: от Middle кандидата чаще ожидается ширина кругозора и знаний (примерно 80% vs 20%). Вы должны собрать понятный высокоуровневый дизайн, закрывающий все функциональные требования, но многие компоненты могут оставаться абстракциями, которые вы проработали и обсудили с интервьюером на поверхностном уровне.

Проверка базовых знаний: интервьюер будет прощупывать базу, чтобы удостовериться, что вы понимаете, что делает каждый компонент. Например, добавив API Gateway, ожидайте вопрос "что он делает" и "как работает".

Смешанный формат ведения: вы должны уверенно вести ранние стадии интервью, но не обязательно проактивно находить все проблемы дизайна. Нормально, если позже интервьюер будет вести обсуждение, задавая вопросы и ставя дополнительные задачи.

Задача Uber: от Middle кандидата ожидается четко определенный API и модель данных, а также высокоуровневый дизайн покрывающий функциональные требования. Кандидат должен указать на необходимость использования гео-пространственного индекса для ускорения поиска по местоположению, а также реализовать, по крайней мере, "хорошее решение" проблемы блокировки запроса на поездку.

Senior

Продвинутый дизайн системы: вы должны быть знакомы с современными принципами проектирования систем: различными технологиями, вариантами их использования и тем, как они сочетаются друг с другом.

Аргументация решений: вы должны уметь ясно объяснять плюсы/минусы архитектурных решений и их влияние на масштабирование, производительность и поддерживаемость, проговаривая компромиссы.

Проактивность и решение проблем: вы должны продемонстрировать сильные навыки решения проблем и проактивный подход. Это подразумевает обнаружение потенциальных проблем в ваших проектах и предложение улучшений. Вам необходимо уметь выявлять и устранять узкие места, оптимизировать производительность и обеспечивать надежность системы.

Задача Uber: от Senior кандидата ожидается, что вы быстро пройдете высокоуровневый дизайн и потратите время на детальное обсуждение как минимум двух из проблем: ускорение proximity-поиска, проблему блокировки запроса на поездку или проблему пиковых нагрузок. Вы также должны быть в состоянии обсудить плюсы и минусы различных вариантов архитектуры, особенно то, как они влияют на
масштабируемость, производительность и удобство обслуживания.

Staff+

Акцент на глубину: от Staff+ кандидата ожидается глубокий разбор нюансов - примерно 40% ширины и 60% глубины. Важна демонстрация того, что, даже если вы не решали именно эту задачу раньше, вы решали достаточно похожих задач в реальном мире, чтобы уверенно спроектировать решение, опираясь на опыт.

Интервьюер понимает, что вы знаете основы (REST, нормализация данных и т. п.), так что вы можете быстро пройти это на high-level дизайне и перейти к самому интересному.

Высокая проактивность: на этом уровне ожидается, что вы будете
самостоятельно выявлять и решать проблемы. Это предполагает не только реагирование на проблемы по мере их возникновения, но и их прогнозирование и реализацию упреждающих решений.

Практическое применение технологий: важно уметь говорить о применяемых технологиях не только в теории, но и как это делается на практике - конфигурации, эксплуатационные нюансы, типичные проблемы.

Решение проблем: ожидаются сильные навыки решения проблем с учетом факторов масштабирования, производительности, надежности и поддерживаемости.

Задача Uber: от Staff+ кандидата ожидается высокое качество решений по сложным проблемам, которые обсуждались выше. Хорошие кандидаты глубоко погружаются как минимум в 3+ ключевых области, демонстрируя не только профессионализм, но и инновационное мышление и способности находить оптимальные решения. Хорошим показателем вашей экспертизы является то, что интервьюер завершает дискуссию, обретя новое понимание или точку зрения.

Разборы задач по System Design:

Проектируем Ticketmaster, сервис бронирования билетов

System Design: проектируем систему бронирования билетов

NowInterview — Fri, 03 Apr 2026 11:11:27 +0000

Перевод на русский язык статьи Design Ticketmaster

Видеоразбор этой задачи на русском языке можно посмотреть здесь - https://www.youtube.com/watch?v=zxeR5bfsNOg

Постановка задачи

🎟️ Что такое Ticketmaster?

Ticketmaster - это онлайн-платформа, позволяющая пользователям
приобретать билеты на концерты, театральные постановки,
спортивные и другие мероприятия.

Функциональные требования

В начале интервью определите функциональные и нефункциональные > требования. Для пользовательских приложений функциональные требования - это формулировки вида "Пользователь может...", а нефункциональные - это характеристики системы вида "Система должна...".

Приоритизируйте 3-4 ключевых функциональных требования. Все остальные требования показывают что вы обладаете продуктовым мышлением, но явно обозначьте это "за рамками задачи", чтобы интервьюер понимал, что эти пункты не входят в дизайн. Уточните, не хочет ли интервьюер увеличить/уменьшить приоритет какого-то требования. Выбор только 3-4 требований помогает оставаться сфокусированным и уложиться во временные рамки интервью.

Основные требования

Пользователи могут просматривать мероприятия.
Пользователи могут искать мероприятия.
Пользователи могут бронировать билеты на мероприятия.

За рамками задачи

Пользователи могут просматривать свои бронирования.
Администраторы или организаторы могут добавлять мероприятия.
Для популярных мероприятий есть динамическое ценообразование.

Нефункциональные требования

Основные требования

Система должна отдавать приоритет доступности при поиске и просмотре мероприятий и согласованности при бронировании, чтобы избежать двойных бронирований.
Система должна быть масштабируемой и способной обрабатывать высокую нагрузку для популярных мероприятий, например 10 млн пользователей для одного события.
Система должна обеспечивать низкую задержку поиска (< 500 мс).
Система ориентирована на чтение и должна поддерживать высокую пропускную способность чтения, соотношение чтения:записи примерно 100:1.

За рамками задачи

Система должна защищать пользовательские данные и соответствовать GDPR.
Система должна быть отказоустойчивой.
Система должна обеспечивать безопасные транзакции для покупок.
Система должна быть хорошо протестирована и легко разворачиваться (CI/CD).
Система должна иметь регулярные резервные копии.

На доске это может выглядеть примерно так:

Описание требований за рамками задачи показывает продуктовое
мышление и дает интервьюеру возможность переопределить
приоритеты. Но это все же необязательная вещь, если
дополнительные идеи не приходят в голову сразу, не тратьте время > и двигайтесь дальше.

Подготовка

Планирование подхода

Прежде чем переходить к проектированию системы, важно на секунду остановиться и продумать стратегию. К счастью, для "продуктовых" задач план обычно простой: последовательно собирать дизайн, проходя по функциональным требованиям одно за другим. Так вы сохраните фокус и не утонете в деталях.

Проектирование API

Для основных функциональных требований понадобятся следующие сущности:

Event (Мероприятие): хранит основную информацию о мероприятии, включая дату, описание, тип и исполнителя или команду.
User (Пользователь): представляет человека, взаимодействующего с системой. Дополнительных пояснений не требуется.
Performer (Исполнитель): представляет индивидуального исполнителя или группу, выступающую или участвующую в мероприятии. Ключевые атрибуты включают имя исполнителя, краткое описание и, возможно, ссылки на работы или профили.
Venue (Площадка): представляет физическое место проведения мероприятия. Каждая сущность площадки включает адрес, вместимость и конкретную карту мест, предоставляющую расположение мест, уникальное для площадки.
Ticket (Билет): хранит информацию, связанную с отдельными билетами на мероприятия. Включает атрибуты, такие как идентификатор мероприятия, детали места (секция, ряд, номер места), цена и статус (доступен или продан). При создании нового мероприятия создается билет для каждого места на площадке на основе карты мест площадки. Сама карта мест хранится как часть сущности Venue (например, JSON-структура или связанная таблица, определяющая секции, ряды и номера мест вместе с координатами для отрисовки). Клиент использует эти данные карты мест в сочетании со статусом каждого билета для отрисовки интерактивного интерфейса выбора мест.
Booking (Бронирование): записывает детали покупки билетов пользователем. Обычно включает идентификатор пользователя, список идентификаторов билетов, общую цену и статус бронирования (например, в процессе или подтверждено). Эта сущность ключевая для управления транзакционным аспектом процесса покупки билетов.

Можно было бы объединить данные бронирования с сущностью Ticket,
но отдельная сущность Booking полезна, когда пользователь
покупает несколько билетов в одной транзакции, поскольку она
объединяет их в рамках одного заказа с общим статусом оплаты и
общей ценой.

Дальше наша цель проста: собрать дизайн, который удовлетворяет функциональным и нефункциональным требованиям. Мы идем последовательно: сначала закрываем функциональные требования, затем усиливаем дизайн нефункциональными.

API для просмотра мероприятий прост. Создаем простой GET эндпоинт, принимающий id и возвращающий детали этого мероприятия.

GET /events/:id -> Event & Venue & Performer & Ticket[]
// билеты используются для отрисовки карты мест на клиенте

В большинстве случаев API и сущности самоописательны и интервьюер
сам понимает, какие данные используются в API. Вы можете
уточнить, хочет ли интервьюер более подробной информации, но
будьте осторожны с избыточной многословностью - нам нужно покрыть
много тем, и перечисление полей объекта Event может быть не
лучшим использованием времени.

Далее, для поиска нам нужен один GET эндпоинт, принимающий набор параметров поиска и возвращающий список мероприятий, соответствующих этим параметрам.

GET /events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_size}&page={page_number} -> Event[]

Когда речь заходит о покупке/бронировании билета, у нас есть POST эндпоинт, который принимает список билетов и детали оплаты и возвращает bookingId.

Позже в дизайне мы превратим это в два отдельных эндпоинта - один для резервирования билета и один для подтверждения покупки, но это хорошая отправная точка.

POST /bookings/:eventId -> bookingId
{
  "ticketIds": string[],
  "paymentDetails": ...
}

Это нормально начинать с простых API и развивать их по мере
продвижения и уточнения дизайна. Достаточно сказать: "Вот простой
API для старта, позже мы его скорректируем, чтобы покрыть более
сложные сценарии".

Высокоуровневое проектирование

1. Пользователи могут просматривать мероприятия

Когда пользователь переходит на /events/:id, он должен видеть детали мероприятия включая карту мест с отображением доступности. На странице также отображаются название и описание мероприятия. Может быть представлена ключевая информация, такая как местоположение, даты мероприятия и факты об исполнителях или командах.

Мы начинаем с разметки основных компонентов для взаимодействия между клиентом и нашими сервисами. Добавим сервис мероприятий, который подключается к базе данных, хранящей данные о мероприятиях, площадках и исполнителях, описанных в основных сущностях выше. Этот сервис будет обрабатывать чтение/просмотр мероприятий.

Давайте пройдем по шагам, что происходит, когда пользователь переходит к просмотру мероприятия:

Клиент делает REST GET запрос с id мероприятия.
API-шлюз затем перенаправляет запрос в сервис мероприятий.
Сервис мероприятий запрашивает в базе данных информацию о мероприятии, площадке и исполнителях и возвращает результаты клиенту.

Компоненты:

Клиенты: пользователи будут взаимодействовать с системой через веб-сайт или приложение клиента. Все клиентские запросы маршрутизируются в бэкенд системы через API-шлюз.
API-шлюз: служит точкой входа для клиентов для доступа к различным сервисам системы. Отвечает в основном за маршрутизацию запросов к соответствующим сервисам, но также может быть настроен для обработки сквозной функциональности, такой как аутентификация, ограничение частоты запросов и логирование.
Сервис мероприятий: ответственен за обработку запросов путем получения необходимой информации о мероприятии, площадке и исполнителях из базы данных и возврата результатов клиенту.
База данных: хранит таблицы мероприятий, исполнителей и площадок.

2. Пользователи могут искать мероприятия

Теперь у нас есть базовая функциональность для просмотра мероприятия. Но как пользователи вообще найдут мероприятия? Когда пользователи впервые открывают ваш сайт, они ожидают возможность поиска предстоящих мероприятий. Этот поиск будет параметризован на основе любой комбинации ключевых слов, артистов/команд, местоположения, даты или типа мероприятия.

Начнем с самого базового варианта - создадим простой сервис, принимающий поисковые запросы. Этот сервис подключится к вашей базе данных и будет выполнять запросы, фильтруя данные в соответствии с параметрами. У этого подхода есть проблемы, но это хорошая стартовая точка. Мы обсудим варианты оптимизации, когда будем погружаться в детали.

Когда пользователь ищет мероприятие:

Клиент делает REST GET запрос с параметрами поиска.
API-шлюз после проверки аутентификации и ограничения частоты пересылает запрос в сервис поиска.
Сервис поиска запрашивает в базе данных мероприятия, соответствующие параметрам поиска, и возвращает их клиенту.

3. Пользователи могут бронировать билеты на мероприятия

Главное, чего мы стараемся избежать - это два пользователя, заплативших за один и тот же билет. Это создало бы неловкую ситуацию на мероприятии. Чтобы обработать эту проблему согласованности, нам нужно выбрать базу данных, поддерживающую транзакции, такую, как PostgreSQL. Это позволит нам
гарантировать, что только один пользователь может забронировать билет за раз.

Дополнительно нам нужно реализовать надлежащие уровни изоляции и либо блокировку на уровне строк, либо оптимистичный контроль
конкурентности
(OCC) для полного предотвращения двойных бронирований. Мы обсудим это подробнее в разделе Погружение в детали.

Это наглядный пример случая, когда высокая конкурентность может
привести к плохим результатам, таким как двойные бронирования.
Управление конкуренцией - это паттерн, который появляется
во многих задачах на проектирование систем, поэтому стоит изучить
его глубже.

Простая реализация бронирования

Новые таблицы: сначала добавляем две новые таблицы в базу данных: Bookings и Tickets. Таблица Bookings будет хранить детали каждого бронирования, включая идентификатор пользователя, идентификаторы билетов, общую цену и статус бронирования. Таблица Tickets будет хранить детали каждого билета, включая идентификатор мероприятия, детали места, цену и статус. Таблица Tickets также будет иметь колонку booking_id, связывающую ее с таблицей Bookings.
Сервис бронирований: отвечает за основную функциональность процесса бронирования билетов. Он использует таблицы Bookings и Tickets для получения, обновления или сохранения соответствующих данных. Он также взаимодействует с платежной системой для обработки платежей. После подтверждения оплаты сервис бронирования обновляет статус билета на "sold".
Платежная система: внешний сервис, ответственный за обработку платежных транзакций. После обработки платежа он уведомляет сервис бронирования о статусе транзакции.

Когда пользователь бронирует билет, происходит следующее:

Пользователь перенаправляется на страницу бронирования, где может ввести данные для оплаты и подтвердить бронирование.
При подтверждении отправляется POST запрос на эндпоинт /bookings с выбранными идентификаторами билетов.
Сервер бронирования инициирует транзакцию для:
проверки доступности выбранных билетов
обновления статуса выбранных билетов на "booked"
создания новой записи бронирования в таблице Bookings

Если транзакция успешна, сервер бронирования возвращает успешный ответ клиенту. В противном случае, если транзакция не удалась, например, потому что другой пользователь уже забронировал билет в то же самое время, мы возвращаем информацию об ошибке клиенту.

Обратите внимание: это означает, что при создании нового
мероприятия нам нужно
создать новый билет для каждого места на площадке. Каждый из них
будет доступен для покупки до тех пор, пока не будет
забронирован.

Вы можете заметить, что несколько сервисов используют одну базу
данных. Правило "одна база данных на сервис" часто повторяется,
но это не жесткое правило. Многие крупнейшие компании мира
используют общие базы данных между сервисами, когда это имеет
смысл. Здесь общая база данных - правильный выбор, потому что
данные тесно связаны (бронирования нуждаются в билетах, билеты
нуждаются в мероприятиях), нам нужны ACID транзакции для
бронирования, и разделение баз данных добавило бы сложности без
реальной пользы. На собеседовании вам следует взвешивать
компромиссы и принимать осмысленные решения, а не повторять
архитектурные догмы.

Вы могли заметить фундаментальную проблему с этим дизайном. Пользователи могут попасть на страницу бронирования, ввести данные для оплаты и затем узнать, что билет, который они хотели, больше не доступен. Это плохой пользовательский опыт, и мы обсудим, как этого избежать чуть позже. Пока у нас простая реализация, удовлетворяющая функциональному требованию.

Потенциальные погружения в детали

После того как мы удовлетворили основные функциональные требования, настало время детальнее углубиться в нефункциональные требования.

Степень, с которой кандидат должен проактивно вести детальное
обсуждение, зависит от его уровня. Например, на собеседовании
уровня Middle вполне разумно, что интервьюер задает вопросы по
деталям реализации. Однако на собеседованиях уровня Senior и
Staff+ ожидаемый уровень инициативы и ответственности кандидата
возрастает. Они должны уметь самостоятельно видеть проблемы в
дизайне и предлагать решения.

1. Как улучшить опыт бронирования путем резервирования билетов?

Текущее решение технически работает, но приводит к плохому пользовательскому опыту. Никто не хочет тратить 5 минут на заполнение формы оплаты, только чтобы узнать, что билеты, которые они хотели, больше не доступны.

Если вы пользовались похожими сервисами для покупки билетов на мероприятия, авиабилетов или бронирования отелей, вы видели таймер обратного отсчета на завершение покупки. Это распространенная техника резервирования билетов для пользователя во время оформления заказа. Давайте обсудим, как можем добавить что-то подобное в наш дизайн.

Нам нужно обеспечить, чтобы билет был зарезервирован для определенного пользователя во время оформления заказа. Также нужно обеспечить, чтобы если пользователь бросит процесс оформления, билет освобождался для покупки другими пользователями. Наконец, нужно обеспечить, чтобы при завершении оформления статус билета менялся на "sold" и бронирование подтверждалось. Вот несколько
способов, как мы можем это сделать:

Плохое решение: Долгоживущие блокировки в базе данных

Подход

Плохое решение, которое многие кандидаты предлагают для этой проблемы - использование долгоживущих блокировок базы данных (иногда называемых "интерактивными транзакциями"). При этом подходе база данных напрямую используется для блокировки конкретной строки в таблице билетов, обеспечивая эксклюзивный доступ первому пользователю, пытающемуся забронировать билет. Это обычно делается с помощью оператора SELECT FOR UPDATE в PostgreSQL, который
блокирует выбранные строки как часть транзакции базы данных. Блокировка строки сохраняется до тех пор, пока транзакция не будет зафиксирована или откачена. В течение этого времени другие транзакции, пытающиеся выбрать ту же строку с SELECT FOR UPDATE, будут заблокированы до снятия блокировки. Это гарантирует,
что только один пользователь может обработать бронирование билета за раз.

Когда речь идет о снятии блокировки, есть два случая для рассмотрения:

1. Если пользователь завершает покупку, транзакция фиксируется, блокировка в базе данных снимается, и статус билета устанавливается в "booked".

2. Если пользователь слишком долго тянет или бросает процесс бронирования, система должна полагаться на их последующие действия или таймауты сессии для снятия блокировки. Это вносит риск бесконечной блокировки билетов при ненадлежащей обработке.

Проблемы

Почему это плохая идея? Блокировки базы данных предназначены для использования на короткие периоды времени. Держать транзакцию открытой долгое время (например, 5-минут) обычно не рекомендуется. Это может неэффективно использовать ресурсы базы данных и увеличивать риск конкуренции за блокировки и риск возникновения
взаимоблокировок. Хотя PostgreSQL поддерживает lock_timeout для отказа в транзакциях, слишком долго ожидающих блокировки, это не элегантное решение для нашего случая, потому что пользователи увидят ошибку вместо того, чтобы быть поставленными в очередь. Реализация таймаута потребует управления на уровне приложения и вносит дополнительные сложности. Наконец, этот подход может плохо
масштабироваться при высокой нагрузке, поскольку длительные блокировки могут привести к увеличению времени ожидания других пользователей и стать потенциальным узким местом производительности. Обработка крайних случаев, таких
как сбои приложения или сетевые проблемы, становится более сложной, так как они могут оставить блокировки в неопределенном состоянии.

Хорошее решение: Статус и время истечения с Cron Job

Подход

Есть решение лучше - заблокировать билет, добавив поле status и expires_at в таблицу билетов. Билет может находиться в 1 из 3 состояний: "available", "reserved", "booked". Это позволяет отслеживать статус каждого билета и автоматически снимать блокировку по достижении времени истечения. Когда пользователь выбирает билет, статус меняется с "available" на "reserved", и в
expires_at записывается текущая метка времени + таймаут резервирования (например, 10 минут).

Теперь подумаем, как обрабатывать разблокировку с этим подходом:

1. Если пользователь завершает покупку, статус меняется на "booked", и блокировка снимается.

2. Если пользователь слишком долго тянет или бросает покупку, статус меняется обратно на "available" по достижении времени истечения, и блокировка снимается. Сложная часть здесь - как обрабатывать время истечения. Мы могли бы использовать Cron Job для периодического запроса строк со статусом "reserved", где прошедшее время превышает длительность блокировки, и затем вернуть их в "available". Это намного лучше, но будет некоторая задержка между истечением времени резервирования и моментом времени когда Cron Job вернет статус строки на "available". В идеале, особенно для популярных мероприятий, блокировка должна сниматься моментально после истечения.

Проблемы

Подход с Cron Job имеет 2 существенных недостатка:

Задержка в разблокировке: существует неотъемлемая задержка между истечением билета и выполнением Cron Job, которая ведет к неэффективности, особенно для мероприятий с высоким спросом. Билеты могут оставаться недоступными для покупки даже после истечения времени, снижая возможности бронирования.
Проблемы надежности: если Cron Job отказывает или работает с задержками, это может вызвать значительные сбои в процессе бронирования билетов, которые приведут к недовольству клиентов и потенциальной потере дохода.

Отличное решение: Неявный статус со status и expires_at

Подход

Мы можем сделать еще лучше, чем наше решение на основе Cron, заметив, что статус доступности любого билета - это один из двух вариантов: "available" ИЛИ "reserved", но время резервирования истекло. В таком случае мы можем создавать короткие транзакции для обновления полей в записи билета (например, изменение
"available" на "reserved" и установка времени истечения на +10 минут). Внутри этих транзакций мы можем подтвердить, что билет доступен перед резервированием или что предыдущее резервирование истекло.

Таким образом, в псевдокоде наша транзакция выглядит так:

1. Начинаем транзакцию.

2. Проверяем, доступен ли текущий билет: "available" ИЛИ ("reserved", но истек).

3. Обновляем status на "reserved", а expires_at на текущее время + 10 минут.

4. Фиксируем транзакцию.

Это гарантирует, что только один пользователь сможет зарезервировать билет, причем билет становится доступным сразу же после истечения времени
резервирования.

Проблемы

Наши операции чтения будут немного медленнее из-за необходимости фильтрации по двум значениям. Мы можем частично решить это, используя материализованные представления или другие возможности современных СУБД вместе с составным индексом. Наша таблица в базе данных также менее читабельна для других потребителей данных, поскольку некоторые резервации на самом деле истекли. Мы
можем решить эту проблему, используя Cron Job или периодическую очистку, как рассказывалось выше, с очень важной разницей: поведение нашей системы не будет затронуто, если эта очистка задержится.

Отличное решение: Распределенная блокировка с TTL

Подход

Другое отличное решение - реализовать распределенную блокировку с TTL (Time To Live, время жизни) с использованием распределенной системы вроде Redis.

Вы можете задаться вопросом: если PostgreSQL уже обеспечивает строгую согласованность, зачем вообще нужен Redis? Ключевая причина в том, что нам нужно временное резервирование, которое автоматически истекает. PostgreSQL изначально не поддерживает TTL на уровне строк - потребовалась бы логика истечения на
уровне приложения (подход с Cron выше). Redis дает встроенное автоматическое истечение ключей, и поскольку он целиком находится в памяти, получение и освобождение блокировки чрезвычайно быстры при высокой конкурентности.

Вот как это будет работать:

1. Когда пользователь выбирает билет, берем блокировку в Redis с уникальным идентификатором (например, ID билета) с предопределенным TTL. Этот TTL действует как автоматическое время истечения блокировки.

2. Если пользователь завершает покупку, статус билета в базе данных обновляется на "booked", и блокировка в Redis вручную освобождается кодом приложения до истечения TTL.

3. Если TTL истекает (указывая, что пользователь не завершил покупку вовремя), Redis автоматически освобождает блокировку и билет становится доступным для бронирования другими пользователями.

Теперь наша таблица Tickets имеет только два состояния: "available" и "booked". Блокировка зарезервированных билетов полностью обрабатывается Redis. Ключом в Redis будет ID билета, а значение - ID пользователя. Таким образом мы можем убедиться, что при подтверждении бронирования пользователь - тот, кто зарезервировал билет.

У нас также нет состояния гонки при получении блокировки: команда Redis SET key value NX EX seconds атомарна, поэтому только один клиент успешно установит ключ. Для многобилетных бронирований (пользователь выбирает несколько мест) можно получать блокировки последовательно для каждого билета. Если любая блокировка не удалась, освобождаем уже полученные. Использование Lua-скрипта в
Redis может сделать получение нескольких блокировок атомарным, если билеты хешируются на один узел Redis.

Проблемы

Сложность при чтении: поскольку резервирования живут в Redis, а не в базе данных, сервису мероприятий нужен способ показывать зарезервированные места как недоступные на карте мест. Один подход - запрашивать Redis для всех заблокированных ID билетов для данного мероприятия (используя Redis Set с ключом event:{eventId}:reserved, который обновляется вместе с каждой блокировкой). Это добавляет сетевой запрос в Redis при чтении, но на практике это быстро. Альтернативно можно делать write-through статуса "reserved" в базу данных при получении блокировки, считая TTL Redis источником истины для истечения блокировки и используя периодическую очистку для удаления устаревших резервирований в базе данных. В любом случае это стоит упомянуть на
собеседовании.

Обработка сбоев: если наша распределенная блокировка по какой-либо причине выйдет из строя, будет период, когда пользовательский опыт ухудшится. Обратите внимание, что мы никогда не получим "двойное бронирование", поскольку наша база данных будет использовать OCC или блокировку на уровне строк для этого.
Недостаток только в том, что пользователи могут получить ошибку после заполнения данных для оплаты, если кто-то их опередит. Это неприятно, но это лучше, чем когда все билеты выглядят недоступными, как было бы при сбое Cron Job в нашем
предыдущем решении.

Истечение TTL во время оплаты: что если TTL блокировки истекает во время обработки платежа? Если блокировка пользователя A истекает на 10-й минуте, но его оплата завершается на 11-й, пользователь B мог перехватить блокировку между этим. В этом редком сценарии транзакция в базе данных в шаге 7 (см. далее) не
удастся для одного из пользователей (OCC обеспечивает, что только одна запись успешна), и мы выдаем автоматический возврат через платежную систему для неудавшегося бронирования. Установите TTL достаточно большим, чтобы минимизировать вероятность этого, и, еще лучше, рассмотрите продление блокировки при инициации оплаты.

Теперь, когда пользователь хочет забронировать билет:

Пользователь выбирает место на интерактивной карте мест. Клиент делает POST запрос на /bookings с ticketId, связанными с этим местом.
API-шлюз маршрутизирует запрос в сервис бронирований.
Сервис бронирований заблокирует этот билет, используя распределенную блокировку на Redis с TTL 10 минут (столько мы будем держать билет).
Сервис бронирований также создаст новую запись бронирования в базе данных со статусом "in_progress".
Мы ответим пользователю только что созданным bookingId и перенаправим его на страницу оплаты.
- Если пользователь остановится здесь, то через 10 минут блокировка автоматически освободится, и билет станет доступен для покупки другим пользователям.
Пользователь производит оплату на сайте платежной системы. Платежная система обрабатывает платеж и уведомляет нас через webhook об успешной оплате.
После подтверждения успешной оплаты от платежной системы webhook нашей системы получает bookingId, встроенный в метаданные платежа. С этим bookingId webhook инициирует транзакцию в базе данных для одновременного обновления таблиц Tickets и Bookings. Конкретно, статус билета, связанного с бронированием, меняется на "sold" в таблице Tickets. Одновременно соответствующая запись бронирования в таблице Bookings помечается как "completed". Обработчик webhook должен быть идемпотентным - платежная система может повторять вызовы webhook при сбое, поэтому обработка одного и того же события оплаты дважды не должна приводить к дублированию изменений состояния. Использование bookingId как ключа идемпотентности и проверка текущего статуса бронирования перед обновлением обеспечивает безопасные повторения.
Теперь билет забронирован.

2. Как обработать десятки миллионов одновременных просмотров для популярных мероприятий?

В наших нефункциональных требованиях мы упомянули, что просмотр и поиск мероприятий должны быть высокодоступными, включая сценарии всплеска трафика. Для этого нам потребуется комбинация балансировки нагрузки, горизонтального масштабирования и кэширования.

Страницы мероприятий получают огромную нагрузку, когда билеты
поступают в продажу - тысячи пользователей обновляют одну и ту же
страницу мероприятия одновременно. Эта экстремальная нагрузка на
чтение делает масштабирование чтения критичным и реализуется
через агрессивное кэширование деталей мероприятий, информации о
площадках и схем мест.

Отличное решение: Кэширование и балансировка нагрузки

Подход

Кэширование:

Приоритизируйте кэширование для данных с высокой частотой чтения и низкой частотой обновления, таких как детали мероприятий (названия, даты, информация о площадках), биографии исполнителей и статичные детали площадок, такие как местоположение и вместимость. Поскольку эти данные не меняются часто, мы можем кэшировать их агрессивно, чтобы значительно минимизировать нагрузку на базу данных и удовлетворить наши требования высокой доступности.
Выбирайте Redis или Memcached как in-memory хранилище данных, используя их высокую скорость для обработки больших объемов операций чтения. Стратегия кэширования read-through обеспечивает доступность данных, с чтением из базы данных в случае промаха кэша и последующим обновлением кэша.
Инвалидация и согласованность кэша:

1. Настройте триггеры базы данных для уведомления системы кэширования об изменениях данных, таких как обновления дат мероприятий или состава исполнителей, для инвалидации соответствующих записей кэша.

2. Реализуйте политику TTL для записей кэша, обеспечивая периодическое обновление. Эти TTL могут быть длинными для статичных данных, таких как информация о площадках, и короткими для часто обновляемых данных, таких как доступность билетов на мероприятия.

Балансировка нагрузки:

Используйте алгоритмы вроде Round Robin или Least Connections для равномерного распределения трафика между экземплярами сервисов. Реализуйте балансировку нагрузки для всех горизонтально масштабируемых сервисов. Это можно не рисовать на доске, но стоит упомянуть устно.

Горизонтальное масштабирование:

Сервис мероприятий не содержит состояния (является stateless), что позволяет нам горизонтально масштабировать его для удовлетворения спроса. Мы можем делать это, добавляя больше экземпляров сервиса и балансируя нагрузку между ними.

Проблемы

Одна из основных сложностей - поддержание согласованности между кэшем и базой данных. Это особенно сложно при частых обновлениях деталей мероприятий (но мы этого не ожидаем).
Управление большим количеством экземпляров создает сложности. Обеспечение плавного развертывания и эффективных процедур отката добавляет операционные сложности.

3. Как обеспечить хороший пользовательский опыт во время мероприятий с высоким спросом с миллионами одновременных бронирований?

На популярных мероприятиях загруженная карта мест быстро устаревает. Пользователи будут расстраиваться, когда снова и снова нажимают на место, только чтобы узнать, что оно уже забронировано. Нам нужно обеспечить, чтобы карта мест всегда была актуальной и пользователи уведомлялись об изменениях в реальном времени.

Иногда лучшее решение - не самое технически сложное.
Отличительная черта Senior/Staff инженера - это способность
решать бизнес-проблемы, иногда мысля вне предполагаемых
ограничений. Нижеприведенные хорошее и отличное решения
иллюстрируют разницу между Senior и Staff кандидатами.

Хорошее решение: SSE для обновления мест в realtime

Подход

Чтобы обеспечить актуальность карты мест, можем использовать Server-Sent Events (SSE) для отправки обновлений клиенту в реальном времени. Это позволит обновлять карту мест, как только место забронировано (или зарезервировано) другим пользователем, без необходимости обновления страницы. SSE - это односторонний
канал связи между сервером и клиентом. Он позволяет серверу отправлять данные клиенту без необходимости запроса со стороны клиента.

Проблемы

Хотя этот подход хорошо работает для умеренно популярных мероприятий, пользовательский опыт все еще пострадает при экстремально популярных мероприятиях. В случае "проблемы Тейлор
Свифт" карта мест заполнится сразу и пользователи окажутся в дезориентированном и ошеломленном состоянии, когда доступные места исчезнут моментально.

Отличное решение: Виртуальная очередь ожидания

Подход

Для экстремально популярных мероприятий мы можем реализовать управляемую администратором систему виртуальной очереди ожидания для управления доступом пользователей во время исключительно высокого спроса. Пользователи размещаются в
этой очереди до того, как смогут увидеть страницу бронирования с актуальной картой мест. Очередь находится перед сервисом бронирования, контролируя поток пользователей, получающих доступ к интерфейсу бронирования, тем самым предотвращая перегрузку системы и улучшая пользовательский опыт. Вот как это работает на высоком уровне:

1. Когда пользователь запрашивает просмотр страницы бронирования, он помещается в виртуальную очередь. Мы устанавливаем постоянное соединение (SSE или WebSocket) с клиентом и добавляем его в очередь. Сама очередь может быть реализована на Redis (используя Sorted Sets с метками времени для упорядочивания). SSE проще, поскольку нам нужна только односторонняя связь сервер-клиент для обновлений позиции, хотя WebSocket подойдет, если ожидается двусторонняя связь.

2. Периодически или по определенным критериям (например, какие-то билеты были забронированы) мы извлекаем пользователей из начала очереди и уведомляем их через их соединение, что они могут перейти к покупке билетов.

3. Одновременно помечаем пользователя как "активного" в Redis (например, добавляем их ID сессии во множество active:{eventId} с TTL). Сервис бронирования проверяет это множество перед разрешением любых запросов на бронирование, отклоняя пользователей, не прошедших через очередь.

Проблемы

Долгое время ожидания в очереди может привести к разочарованию пользователей, особенно если предполагаемое время ожидания неточно или очередь движется медленно. Отправляя обновления клиенту в реальном времени, мы можем снизить этот риск, предоставляя пользователям постоянную обратную связь об их позиции в
очереди и предполагаемом времени ожидания.

Хотя мы бы не стали использовать SSE для этого случая, многие системы включают какой-то аспект отправки обновлений в реальном времени клиенту. Мы описали все подходы в паттерне Обновления в реальном времени.

4. Как обеспечить быстрый поиск мероприятий?

Наша текущая реализация поиска не справится. Запросы на поиск мероприятий по ключевым словам в названии, описании или других полях потребуют полного сканирования таблицы для оператора LIKE. Это может быть очень медленно, особенно с ростом количества мероприятий.

-- медленный запрос
SELECT *
FROM Events
WHERE name LIKE '%Тейлор%'
  OR description LIKE '%Тейлор%'

Давайте рассмотрим некоторые стратегии для улучшения производительности поиска и обеспечения наших требований низкой задержки.

Хорошее решение: Индексация и оптимизация SQL-запросов

Подход

Создайте индексы на таблицах Events, Performers и Venues для улучшения производительности запросов. Индексы позволяют быстрее извлекать данные, уменьшая количество строк для сканирования. Нужно индексировать колонки, часто используемые в поисковых запросах, такие как название мероприятия, дата мероприятия, имя исполнителя и местоположение площадки.
Оптимизируйте запросы для улучшения производительности. Применяйте такие техники, как использование EXPLAIN для анализа планов выполнения запросов, избегание запросов SELECT *, использование LIMIT для ограничения количества возвращаемых строк. Дополнительно использование UNION вместо OR для объединения нескольких запросов иногда может улучшить производительность.

Проблемы

Стандартные индексы менее эффективны для запросов с частичным совпадением строк, например, поиск "Тейлор" вместо полного "Тейлор Свифт".
Хотя индексы улучшают производительность запросов, они также могут увеличить требования к хранению и замедлить операции записи, так как каждая вставка или обновление может потребовать обновления индекса.
Нужно найти правильный баланс между количеством индексов и общей производительностью базы данных, особенно учитывая разнообразные и сложные паттерны запросов в системе бронирования билетов.

Отличное решение: Полнотекстовые индексы в базе данных

Подход

Мы можем расширить базовую стратегию индексации описанную выше для использования полнотекстовых индексов в нашей базе данных, если они доступны. PostgreSQL имеет встроенный полнотекстовый поиск с использованием tsvector и GIN индексов, а MySQL предлагает свой полнотекстовый поиск. Ни один из них не использует Lucene, на котором базируется Elasticsearch. Они делают запросы для конкретных строк вроде "Тейлор" или "Свифт" намного быстрее, чем полное сканирование таблицы с помощью LIKE.

Проблемы

Полнотекстовые индексы требуют дополнительного места для хранения и могут быть медленнее для запросов, чем стандартные индексы.
Полнотекстовые индексы могут быть сложнее в поддержке, так как требуют специальной обработки как в запросах, так и при обслуживании базы данных.

Отличное решение: Полнотекстовая поисковая система

Подход

Elasticsearch - мощная поисковая система, превосходно справляющаяся с полнотекстовым поиском, выполнением сложных запросов и обработкой объемного трафика. В своей основе Elasticsearch использует инвертированные индексы - ключевая особенность, делающая его высокоэффективным для поисковых операций. Инвертированные индексы
сопоставляют каждое уникальное слово с документами или записями, в которых оно встречается, что значительно ускоряет поисковые запросы.

Чтобы убедиться, что данные в Elasticsearch всегда синхронизированы с данными в нашей SQL базе данных, мы можем использовать механизм Change Data Capture (CDC). Этот механизм фиксирует изменения в PostgreSQL, такие как вставки, обновления и удаления, и реплицирует их в индексы Elasticsearch.
Мы можем включить функцию нечеткого поиска (fuzzy search) в Elasticsearch, которая допускает толерантность к ошибкам в поисковых запросах. Так мы можем обрабатывать опечатки и небольшие вариации в написании, такие как "Тейлор Свивт" и "Тайлер Свифт". Это было бы очень сложно сделать только с SQL базой.

Проблемы

Поддержание кластера Elasticsearch добавляет дополнительную инфраструктурную сложность и стоимость.
Поддержание синхронизации индексов Elasticsearch с PostgreSQL может быть сложным и требует надежного механизма для обеспечения согласованности данных.

5. Как ускорить часто повторяющиеся поисковые запросы и снизить нагрузку на поисковую инфраструктуру?

Хорошее решение: Стратегии кэширования с Redis

Подход

Мы можем использовать механизмы кэширования, такие как Redis или Memcached для хранения результатов часто выполняемых поисковых запросов. Это снижает нагрузку на поисковую инфраструктуру путем обслуживания повторяющихся запросов из кэша
вместо многократного обращения к базе данных или поисковой системе.

Дизайн ключей: создавайте ключи кэша на основе параметров поискового запроса для уникальной идентификации каждого запроса.
Time-To-Live (TTL): устанавливайте подходящие TTL для кэшированных данных, чтобы обеспечить актуальность и релевантность информации.

Например, запись кэша может выглядеть так:

{
  "key": "search:keyword=Тейлор&start=2021-01-01&end=2021-12-31",
  "value": [event1, event2, event3],
  "ttl": 60 * 60 * 24 // 24 часа
}

Проблемы

Эффективное управление инвалидацией кэша может быть сложным. Устаревшие или неактуальные данные в кэше могут приводить к отдаче пользователям неправильных результатов поиска. Проблема усугубляется, если кэшировать результаты нечеткого поиска. Можно использовать комбинацию TTL и триггеров инвалидации кэша, построенных на основе тегов кэша, для обеспечения согласованности данных.
Частые промахи кэша могут приводить к повышенной нагрузке на поисковую инфраструктуру, особенно в пиковые часы.

Отличное решение: Кэширование результатов запросов и CDN

Подход

К нашему удобству, Elasticsearch имеет встроенные возможности кэширования, которые можно использовать для хранения результатов частых запросов. Это снижает нагрузку на обработку запросов самой поисковой системы. Elasticsearch поддерживает кэши запросов на уровне шардов для результатов фильтров, плюс отдельный кэш запросов для кэширования полных поисковых ответов, что особенно полезно для запросов с агрегацией. Это можно использовать для адаптивных
стратегий кэширования, когда система обучается со временем и кэширует результаты наиболее часто выполняемых запросов.

Также можем использовать CDN для кэширования результатов поиска географически ближе к пользователю, снижая задержку и улучшая время ответа. Заметьте, это имеет смысл только если результаты поиска не персонализированы, то есть один и тот же поисковый запрос возвращает одни и те же результаты для всех пользователей.

Проблемы

Обеспечение согласованности между кэшированными и актуальными данными требует сложных механизмов синхронизации. Нужно убедиться в инвалидации кэша при каждом изменении базовых данных, например, при объявлении нового мероприятия.
Этот подход требует большей инфраструктурной поддержки, включая интеграцию с CDN и управление адаптивными системами кэширования.

По мере прохождения детальных разборов вы должны обновлять дизайн для отражения вносимых изменений. Итоговый дизайн может выглядеть примерно так:

Визуальная коммуникация важна. Ваш интервьюер занят. Скорее
всего, он завершит собеседование, перейдет к списку встреч,
длящемуся до конца дня и усталый вернется домой, а на следующее
утро вспомнит, что нужно написать отзыв о проведенном вчера
собеседовании. Затем он откроет ваш дизайн и попытается
вспомнить, что вы сказали. Облегчите ему жизнь и улучшите свои
шансы, сделав визуальный дизайн максимально ясным.

Что ожидается на каждом уровне?

Middle

Проверка базовых знаний: интервьюер будет прощупывать базу, чтобы удостовериться, что вы понимаете, что делает каждый компонент. Например, добавив API-шлюз, ожидайте вопрос "что он делает" и "как работает".

Задача Ticketmaster:от Middle кандидата ожидается четко определенный API и модель данных, а также высокоуровневый дизайн покрывающий функциональные требования: просмотр и бронирования мероприятий. Кандидат должен быть способен решить проблему "двойных бронирований" как минимум "хорошим решением" с полем статуса, таймаутом и Cron Job.

Senior

Глубина экспертизы: от Senior кандидата ожидания смещаются к глубине - примерно 60% ширины и 40% глубины. Нужно уметь уходить в детали там, где у вас есть практический опыт. Критично продемонстрировать глубокое понимание ключевых концепций и технологий, релевантных задаче.

Продвинутый дизайн системы: вы должны быть знакомы с продвинутыми принципами проектирования систем. Например, необходимо знание того, как использовать оптимизированное для поиска хранилище данных вроде Elasticsearch для поиска мероприятий. Также ожидается понимание использования распределенной блокировки для резервирования билетов и обсуждение детальных стратегий масштабирования (допустимо, если для этого потребовались подсказки от интервьюера), включая шардирование и репликацию.

Задача Ticketmaster: от Senior кандидата ожидается, что вы быстро пройдете высокоуровневый дизайн и потратите время на детальное обсуждение оптимизации поиска, обработки "двойных бронирований" (приходя к распределенной блокировке или другому качественному решению) и даже обсуждение обработки популярных мероприятий, демонстрируя глубину экспертизы в управлении масштабируемостью и надежностью при высокой нагрузке.

Staff+

Акцент на глубину: от Staff+ кандидата ожидается глубокий разбор нюансов - примерно 40% ширины и 60% глубины. Важна демонстрация того, что, даже если вы не решали именно эту задачу раньше, вы решали достаточно похожих задач в реальном
мире, чтобы уверенно спроектировать решение, опираясь на опыт.

Задача Ticketmaster: от Staff+ кандидата ожидается высокое качество решений по сложным проблемам, которые обсуждались выше. Хорошие кандидаты глубоко погружаются как минимум в 2-3 ключевых области, демонстрируя не только профессионализм, но и инновационное мышление и способности находить оптимальные решения. Хорошим показателем вашей экспертизы является то, что интервьюер
завершает дискуссию, обретя новое понимание или точку зрения.

Разборы задач по System Design:

Проектируем Uber, сервис заказа такси