Перевод на русский язык статьи 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 индексами это плохо работает для многомерных данных вроде координат.
Что можно сделать, чтобы разобраться с этими проблемами?
Подход Плохое решение - это наш текущий high-level дизайн: записывать каждое обновление локации в базу и выполнять proximity‑поиск по этим сырым данным. Этот подход плохо масштабируется из‑за высокой частоты обновлений и делает proximity‑поиск неэффективными и медленными. Этот метод приведет к перегрузке системы, высокойПлохое решение: Прямая запись в базу и proximity‑поиск
задержке и ухудшению пользовательского опыта, что сделает его непригодным для приложения масштаба Uber.
Подход Вместо записи каждого обновления напрямую в базу мы агрегируем обновления за небольшой интервал времени и записываем их пакетами. Это снижает количество операций записи, а также повышает пропускную способность записи и уменьшает количество конфликтов. Для поиска ближайших водителей используем специализированную геопространственную базу данных с индексами, например на основе деревьев квадрантов (quadtrees). Если использовать PostgreSQL, у него есть расширение Проблемы Интервал пакетных записей приводит к задержке: данные о локациях становятся слегка устаревшими, а это ведет к ухудшению качества подбора водителей.Хорошее решение: Пакетная обработка и специализированная гео‑база
Деревья квадрантов особенно хорошо подходят для двумерных пространственных данных, таких как географические координаты, поскольку они рекурсивно делят пространство на квадранты, что значительно ускоряет proximity‑поиск.
PostGIS, которое позволяет использовать
геопространственные типы и функции без необходимости отдельного хранилища.
Подход Мы можем устранить ограничения предыдущих решений, используя in‑memory хранилище вроде Redis, которое поддерживает геопространственные типы и команды. Это позволяет нам обрабатывать обновления местоположения водителей в режиме реального времени и эффективно выполнять proximity-поиск, одновременно минимизируя затраты на хранение за счет автоматического истечения срока действия данных. Redis использует geohashing для кодирования широты и долготы в единое строковое значение, которое хранится в отсортированных множествах. Redis предоставляет специализированные команды, такие как Пакетная обработка больше не нужна: Redis справляется с большим потоком обновлений в реальном времени. Кроме того, Redis автоматически удаляет данные на основе заданного времени жизни (TTL), что позволяет нам сохранять только самые последние обновления местоположения и избегать ненужных затрат на хранение. Проблемы Главная проблема этого подхода - надежность. Поскольку Redis хранит все данные в памяти (in‑memory), возможны потери данных при сбое. Однако эти риски можно смягчить несколькими способами: Даже при потере данных ущерб минимален: локации обновляются каждые 5 секунд, и система быстро восстанавливает состояние.Отличное решение: In‑memory гео‑хранилище реального времени
GEOADD и GEOSEARCH, которые эффективно обрабатывают обновления в реальном времени и proximity‑поиск. Команда GEOSEARCH, которая появилась в Redis 6.2, заменяет и расширяет функциональность старых команд GEORADIUS и GEORADIUSBYMEMBER, давая больше гибкости и улучшая производительности.
2. Как снизить перегрузку из‑за частых обновлений локаций без потери точности?
Частые обновления локаций перегружают сеть и серверы, что может замедлять работу системы и ухудшать пользовательский опыт. Большинство кандидатов предлагают обновлять локацию водителя каждые 5 секунд или около того. Можем ли мы разумно уменьшить количество обновлений, сохраняя при этом точность?
Подход Мы можем решить эту проблему, внедрив адаптивные интервалы обновления локаций, которые динамически регулируют частоту обновления в зависимости от таких факторов как скорость, направление движения, близость к ожидающим запросам на Приложение водителя использует датчики устройства и определенные алгоритмы для определения оптимального интервала. Если водитель стоит или движется медленно - обновления могут отсылаться реже. И наоборот, если водитель движется быстро или часто меняет направление, обновления отправляются чаще. Проблемы Основная сложность этого подхода - корректно построить эффективный алгоритм определения оптимальной частоты обновления. Он может потребовать тщательного тестирования в несколько итераций. Но если все сделать правильно, это значительно сократит количество обновлений и повысит эффективность системы.Отличное решение: Адаптивные интервалы обновлений
поездку и статус водителя.
Не пренебрегайте клиентом, думая о своем дизайне. У многих
кандидатов появляется привычка рисовать маленький прямоугольник
"клиент" и двигаться дальше. Во многих случаях нам нужна логика
на стороне клиента для повышения эффективности и масштабируемости
нашей системы. Как вы видели, мы можем уменьшить количество
обновлений, используя встроенные датчики и алгоритмы для
определения оптимального интервала их отправки. Аналогичным
образом, для сервиса загрузки файлов клиент отвечает за разбитие
на куски и сжатие.
3. Как предотвратить назначение нескольких поездок одному водителю?
Мы определили сильную согласованность при подборе водителя как ключевое нефункциональное требование. Это означает что каждый заказ посылается на рассмотрение только одному водителю, И один водитель в каждый момент времени имеет только один заказ на рассмотрении. У водителя есть 10-15 секунд на принятие/отклонение заказа, после чего система переходит к следующему водителю. Если вы рассматривали задачу проектирования сервиса бронирования билетов, это очень
похоже, поскольку мы гарантируем что билет продается только один раз, и он зарезервирован на определенное время при оформлении заказа.
Подход Основная идея заключается в том, что нам нужно заблокировать водителей, чтобы предотвратить одновременную отправку нескольких запросов на поездку одному и тому же водителю. Один из подходов - использовать блокировку на уровне приложения, при которой каждый экземпляр сервиса подбора водителя помечает запрос на поездку как "locked" при его отправке водителю. Затем он запускает таймер на время блокировки. Если водитель не принимает поездку в течение этого периода, сервер снимает блокировку и делает запрос доступным для других водителей. Проблемы У этого подхода несколько проблем:Плохое решение: Блокировка на уровне приложения и проверка таймаута
Подход Чтобы решить проблему координации, мы можем переместить блокировку в базу данных. Это позволяет нам использовать встроенные транзакционные возможности базы данных, чтобы гарантировать, что только один экземпляр может одновременно заблокировать запрос на поездку. Когда мы отправляем запрос водителю, мы обновляем статус этого водителя на "outstanding_request". Если водитель принимает запрос, мы обновляем статус на "accepted", а если отклоняет, мы Проблемы Хотя мы решили проблему координации, мы по-прежнему сталкиваемся с проблемами, связанными с использованием таймаута в памяти для разблокировки, если водитель не отвечает. Если сервис поездок выйдет из строя или будет перезапущен, таймаут будет потерян, а блокировка останется на неопределенный срок. Это распространенная проблема с таймаутами в памяти, и причина их избегать, когдаХорошее решение: Блокировка через статус в базе данных и таймаут
обновляем статус на "available". Затем мы можем использовать простой механизм таймаута в сервисе поездок, чтобы гарантировать, что блокировка будет снята, если водитель не ответит в течение 10 секунд.
это возможно. Одним из решений является создание cron-задания, которое будет периодически запускаться для проверки наличия блокировок с истекшим сроком действия и их снятия. Это будет работать, но добавляет ненужную сложность и задерживает разблокировку запроса на поездку.
Подход Чтобы решить проблему таймаута, мы можем использовать распределенную блокировку, реализованную с помощью in-memory хранилища, такого как Redis. Когда водителю отправляется запрос на поездку, создается блокировка с уникальным идентификатором (например, Проблемы Основная проблема этого подхода - зависимость системы от доступности и производительности Redis. Нам нужны надежные стратегии мониторинга и аварийного переключения, чтобы гарантировать, что система может быстро восстановиться послеОтличное решение: Распределенная блокировка с TTL
driverId) и TTL = 10 секунд. Сервис подбора
водителей пытается получить блокировку driverId в Redis. Если блокировка успешно получена, это означает, что ни один другой экземпляр сервиса не сможет отправить запрос на поездку тому же водителю до тех пор, пока не истечет срок действия блокировки или она не будет снята. Если водитель соглашается на поездку
в течение 10 секунд, сервис подбора водителя обновляет статус поездки на "accepted" в базе данных, и блокировка снимается в Redis. Если водитель не соглашается на поездку, блокировка в Redis немедленно снимается и водитель становится доступным для новых запросов на поездку.
сбоев и что блокировки не будут потеряны.
4. Как гарантировать, что запросы поездок не теряются в пиковые периоды?
В периоды пиковой нагрузки система может получать большое количество запросов на поездки, которые мы не сможем обработать и они будут отклонены. Например, это часто происходит во время особых мероприятий или праздников, когда спрос резко вырастает. Нам также необходимо защититься от случаев, когда один из серверов сервиса подбора водителя выходит из строя или перезапускается, что не должно приводить к потере запросов на поездки.
Подход Самый простой подход - обрабатывать запросы на поездки по мере их поступления без какой-либо системы очередей (как это сделано в текущем дизайне). Проблемы Основная проблема этого подхода заключается в том, что он плохо масштабируется в периоды высокой нагрузки. По мере увеличения количества входящих запросов и перегрузки система начинает отбрасывать запросы, которые не может обработать, что приводит к ухудшению пользовательского опыта. Мы можем горизонтально Кроме того, если один из экземпляров сервиса выходит из строя, все запросы на поездки, обрабатываемые этим экземпляром, будут потеряны. Это приведет к тому, что пассажиры будут бесконечно ждать подбора, который так и не случится.Плохое решение: Без очереди
масштабировать наш сервис подбора водителей, но при внезапном всплеске спроса мы не сможем масштабироваться достаточно быстро, чтобы полностью предотвратить потерю запросов.
Подход Чтобы решить эту проблему, мы можем добавить очередь, куда попадает запрос на поездку. Сервис подбора водителей обрабатывает запросы из очереди в порядке их поступления и может масштабироваться горизонтально в зависимости от размера очереди. Этот подход также позволяет гарантировать, что ни один запрос не будет отброшен или потерян. Мы также можем разделить очереди по географическим регионам для дальнейшего повышения эффективности. Мы могли бы использовать распределенную очередь сообщений, такую как Kafka, которая позволяет нам подтверждать обработку сообщения только после того, как мы успешно подобрали водителя. Таким образом, если экземпляр сервиса подбора выйдет из строя, запрос на поездку все равно будет находиться в очереди, и его подберет другой Проблемы Основная проблема этого подхода - добавленная сложность. Нам необходимо обеспечить масштабируемость, отказоустойчивость и высокую доступность очереди. Мы можем решить эту проблему, используя managed сервис очередей, такой как Amazon SQS или Kafka, который предоставляет требуемые характеристики "из коробки". Это позволяет нам сосредоточиться на бизнес-логике нашей системы, не Еще одна проблема в том, что обработка некоторых запросов может занимать много времени, блокируя другие "более быстрые" запросы. Это распространенная проблема с очередями FIFO, и ее можно решить, используя очередь с приоритетом. Это позволит нам определять приоритетность запросов на основе таких факторов, какОтличное решение: Очередь и динамическое масштабирование
экземпляр. Такой подход гарантирует, что ни один запрос на поездку не будет потерян при сбое.
беспокоясь об инфраструктуре.
близость водителя, рейтинг водителя, класс поездки и так далее.
5. Что делать, если водитель не отвечает вовремя?
Наша система прекрасно работает, когда водители либо принимают, либо отклоняют заявку на поездку. Но если водитель сделал перерыв и не реагирует на запросы, мы должны гарантировать, что запрос на поездку будет продолжать обрабатываться, перенаправляя запрос следующему водителю.
Процессы которые требуют реакции или действий от человека часто
сигнализируют, что > мы столкнулись с паттерном Многошаговые
процессы. На самом деле, Uber является первоначальным автором
проекта с открытым исходным кодом Cadence, который лег в
основу Temporal - системы надежного исполнения, созданную
специально для таких случаев.
Подход Мы можем реализовать очередь с задержками, чтобы автоматически повторять запросы на поездку со следующим доступным водителем, если текущий водитель не отвечает в течение таймаута. Когда запрос на поездку отправляется водителю, мы одновременно планируем отложенное сообщение в очереди (например, Amazon SQS позволяет добавить сообщение с таймаутом видимости, в нашем случае 10 секунд). Отложенное сообщение содержит сведения о запросе и водителе, с которым первоначально связались. При обработке отложенного сообщения система проверяет, не назначена ли еще поездка. Если это так, запрос автоматически переходит к следующему водителю, одновременно планируя еще одно отложенное сообщение для нового Проблемы И опять сложность - основная проблема такого подхода. Если водитель соглашается на поездку, нам необходимо убедиться, что отложенное сообщение обрабатывается корректно и не приводит к неправильному переназначению поездки. Кроме того, этот подход требует тщательной координации между очередью и сервисом подбора водителей, чтобы обеспечить согласованность и избежать состояний гонки.Хорошее решение: Очередь с задержками
водителя и так далее.
Подход Эти системы обеспечивают встроенную поддержку таймаутов, повторных попыток и управления состоянием таким образом, чтобы выдерживать сбои и перезапуски сервисов. Весь процесс подбора водителя моделируется как workflow, который может обрабатывать сложную бизнес-логику, при этом постоянно сохраняет свое состояние, Например, Temporal workflow может выглядеть так: Проблемы И опять мы добавляем дополнительную сложность, внедряя систему оркестрации workflow. Это требует от инженеров изучения новых концепций и инструментов и добавляет в систему еще один компонент, который необходимо мониторить и обслуживать. Однако преимущества гарантированного выполнения, встроенной отказоустойчивости и упрощенной бизнес-логики часто перевешивают эти проблемы, особенно для критически важных систем, где отброшенные запросы напрямую влияют на финансовые показатели и удобство пользователей.Отличное решение: Надежное исполнение (durable execution)
поэтому даже в случае сбоя процесс можно возобновить с того места, где он был остановлен.
6. Как дальше масштабировать систему, снижая задержку и повышая пропускную способность?
Подход Самый простой путь - вертикальное масштабирование, при котором мы увеличиваем мощность существующих серверов, добавляя больше CPU, памяти или дисков. Это быстрый и простой способ увеличить емкость, но он имеет ряд ограничений. Проблемы Это решение плохое по многим причинам. Во-первых, это дорого и требует простоя для обновления серверов. Во-вторых, мы не сможем вертикально масштабироваться бесконечно. Наконец, это решение не является отказоустойчивым. Если сервер выйдет из строя, вся система выйдет из строя. На интервью обсуждать этот вариант вряд ли стоит, поскольку для системы такого масштаба он непрактичен.Плохое решение: Вертикальное масштабирование
Подход Лучшим подходом является горизонтальное масштабирование путем добавления дополнительных серверов. Мы можем сделать это, разделив наши данные по географическому принципу и используя реплики чтения для повышения пропускной способности чтения. Важно отметить, что это не только позволяет нам масштабироваться, но и снижает задержку за счет уменьшения расстояния между клиентом и сервером. Все компоненты системы: сервисы, очереди сообщений и базы данных можно шардировать географически. Единственный случай, когда нам Проблемы Главная сложность - правильное управление шардированием. Нам необходимо гарантировать, что данные распределяются равномерно по шардам и что система может обрабатывать сбои и выполнять перебалансировку. Мы можем решить это, используя согласованное хеширование для распределения данных по шардам и реализуя стратегию репликации для повышения отказоустойчивости.Отличное решение: Гео-шардирование и реплики чтения
понадобится межрегиональное вычисление (например, запрос по нескольким шардам), - это когда мы выполняем proximity-поиск на границе нескольких шардов.
Итоговая архитектура нашей системы может выглядеть примерно так:
Что ожидается на каждом уровне?
Хорошо, мы обсудили много всего. Возникает резонный вопрос: "сколько из этого реально ожидается от меня на интервью?" Разберем по уровням.
Middle
Ширина vs глубина: от Middle кандидата чаще ожидается ширина кругозора и знаний (примерно 80% vs 20%). Вы должны собрать понятный высокоуровневый дизайн, закрывающий все функциональные требования, но многие компоненты могут оставаться абстракциями, которые вы проработали и обсудили с интервьюером на поверхностном уровне.
Проверка базовых знаний: интервьюер будет прощупывать базу, чтобы удостовериться, что вы понимаете, что делает каждый компонент. Например, добавив API Gateway, ожидайте вопрос "что он делает" и "как работает".
Смешанный формат ведения: вы должны уверенно вести ранние стадии интервью, но не обязательно проактивно находить все проблемы дизайна. Нормально, если позже интервьюер будет вести обсуждение, задавая вопросы и ставя дополнительные задачи.
Задача Uber: от Middle кандидата ожидается четко определенный API и модель данных, а также высокоуровневый дизайн покрывающий функциональные требования. Кандидат должен указать на необходимость использования гео-пространственного индекса для ускорения поиска по местоположению, а также реализовать, по крайней мере, "хорошее решение" проблемы блокировки запроса на поездку.
Senior
Глубина экспертизы: от Senior кандидата ожидания смещаются к глубине - примерно 60% ширины и 40% глубины. Нужно уметь уходить в детали там, где у вас есть практический опыт.
Продвинутый дизайн системы: вы должны быть знакомы с современными принципами проектирования систем: различными технологиями, вариантами их использования и тем, как они сочетаются друг с другом.
Аргументация решений: вы должны уметь ясно объяснять плюсы/минусы архитектурных решений и их влияние на масштабирование, производительность и поддерживаемость, проговаривая компромиссы.
Проактивность и решение проблем: вы должны продемонстрировать сильные навыки решения проблем и проактивный подход. Это подразумевает обнаружение потенциальных проблем в ваших проектах и предложение улучшений. Вам необходимо уметь выявлять и устранять узкие места, оптимизировать производительность и обеспечивать надежность системы.
Задача Uber: от Senior кандидата ожидается, что вы быстро пройдете высокоуровневый дизайн и потратите время на детальное обсуждение как минимум двух из проблем: ускорение proximity-поиска, проблему блокировки запроса на поездку или проблему пиковых нагрузок. Вы также должны быть в состоянии обсудить плюсы и минусы различных вариантов архитектуры, особенно то, как они влияют на
масштабируемость, производительность и удобство обслуживания.
Staff+
Акцент на глубину: от Staff+ кандидата ожидается глубокий разбор нюансов - примерно 40% ширины и 60% глубины. Важна демонстрация того, что, даже если вы не решали именно эту задачу раньше, вы решали достаточно похожих задач в реальном мире, чтобы уверенно спроектировать решение, опираясь на опыт.
Интервьюер понимает, что вы знаете основы (REST, нормализация данных и т. п.), так что вы можете быстро пройти это на high-level дизайне и перейти к самому интересному.
Высокая проактивность: на этом уровне ожидается, что вы будете
самостоятельно выявлять и решать проблемы. Это предполагает не только реагирование на проблемы по мере их возникновения, но и их прогнозирование и реализацию упреждающих решений.
Практическое применение технологий: важно уметь говорить о применяемых технологиях не только в теории, но и как это делается на практике - конфигурации, эксплуатационные нюансы, типичные проблемы.
Решение проблем: ожидаются сильные навыки решения проблем с учетом факторов масштабирования, производительности, надежности и поддерживаемости.
Задача Uber: от Staff+ кандидата ожидается высокое качество решений по сложным проблемам, которые обсуждались выше. Хорошие кандидаты глубоко погружаются как минимум в 3+ ключевых области, демонстрируя не только профессионализм, но и инновационное мышление и способности находить оптимальные решения. Хорошим показателем вашей экспертизы является то, что интервьюер завершает дискуссию, обретя новое понимание или точку зрения.
Разборы задач по System Design:
