DEV Community: NowInterview

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

NowInterview — Sat, 16 May 2026 16:18:13 +0000

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

Больше статей и разборов по System Design: https://nowinterview.ru

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

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

☁️ Что такое Dropbox?

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

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

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

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

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

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

Стоит отметить, что существуют задачи System Design, касающиеся
самого хранилища больших бинарных (blob) объектов. Это выходит за
рамки данной задачи, но вы можете самостоятельно изучить этот
вопрос, чтобы понять, как работает и как устроено объектное
хранилище.

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

Система должна обладать высокой доступностью (приоритет доступности над согласованностью данных).
Система должна поддерживать файлы размером до 50 ГБ.
Система должна быть безопасной и надежной. Должна существовать возможность восстанавливать файлы в случае их потери или повреждения.
Система должна обеспечивать максимально быструю загрузку, скачивание и синхронизацию.

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

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

Вот как это может выглядеть на доске:

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

Подготовка

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

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

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

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

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

В случае Dropbox основные сущности предельно просты:

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

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

API - основной интерфейс, через который пользователи взаимодействуют с системой. Его полезно определить с самого начала, поскольку он направляет high-level дизайн. Обычно нам нужен один эндпоинт на каждое функциональное требование.

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

POST /files
{
  File,
  FileMetadata
}

Для скачивания файла мы можем использовать эндпоинт:

GET /files/{fileId} -> File & FileMetadata

Имейте в виду, что ваш API может меняться или развиваться по мере
проектирования. В данном случае API для загрузки и скачивания
значительно эволюционируют, поскольку мы взвешиваем компромиссы
различных подходов в нашем high-level дизайне (подробнее об этом
позже). Вы можете заранее сообщить об этом интервьюеру, сказав:
"Я собираюсь описать несколько простых API эндпоинтов, но,
возможно, вернусь к ним и улучшу их по мере того, как мы будем
углубляться в проектирование".

Для обмена файлами мы можем использовать следующий эндпоинт:

POST /files/{fileId}/share
{
  User[] // Пользователи, с которыми поделились
}

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

GET /files/{fileId}/changes -> FileMetadata[]

В каждом из этих запросов информация о пользователе передается в
заголовках (через session token или auth token). Это
распространенный паттерн, так мы можем обеспечивать
аутентификацию/авторизацию и безопасность. Не стоит передавать
пользовательские данные в теле запроса: в этом случае их можно
легко подделать.

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

1. Пользователи могут загружать файлы с любого устройства

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

Где мы храним содержимое файла (бинарные данные)?
Где мы храним метаданные файла?

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

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

{
  "id": "12",
  "name": "file.txt",
  "size": 2000,
  "mime_type": "text/plain",
  "uploaded_by": "user1"
}

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

Плохое решение: Загрузка на наш сервер

Подход

Самый простой подход - загружать файлы непосредственно на наш бэкенд-сервер (назовем его файловый сервис) и хранить их там. Наш запрос POST /files будет принимать файл и метаданные, а затем сохранять файл в локальной файловой системе сервера, а метаданные в нашей базе данных. Это разумный подход для небольшого
приложения, но он плохо масштабируется и ненадежен.

Проблемы

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

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

Хорошее решение: Сохраняем в объектное хранилище

Подход

Более эффективным подходом является хранение файла в объектном хранилище, таком как Amazon S3 или Google Cloud Storage. Когда пользователь загружает файл на наш бэкенд, мы можем отправить его в объектное хранилище и сохранить метаданные в нашей базе данных. Мы можем хранить (в теории) неограниченное количество файлов в объектном хранилище, поскольку оно само позаботится о масштабировании. Это также более надежно. Если наш сервер выйдет из строя, мы не потеряем доступ к нашим файлам. Мы также можем воспользоваться такими функциями объектного хранилища, как
политики жизненного цикла для автоматического удаления старых файлов и версионирование для отслеживания изменений файлов при необходимости (хотя это выходит за рамки данной задачи).

Проблемы

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

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

Отличное решение: Загрузка напрямую в объектное хранилище

Подход

Наилучший подход - загружать файл непосредственно в объектное хранилище с клиентской стороны. Это быстрее и дешевле, чем предварительная загрузка файла в наш бэкенд. Мы можем использовать предварительно подписанный URL-адрес (presigned URL),
который пользователь сможет использовать для прямой загрузки файла в объектное хранилище. После загрузки файла объектное хранилище отправит уведомление в наш бэкенд, чтобы мы могли сохранить метаданные.

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

Запрос предварительно подписанного URL-адреса (который генерируется с помощью S3 SDK), сохранение метаданных файла в нашей базе данных со статусом "uploading".

POST /files/presigned-url -> PresignedUrl
{
  FileMetadata
}

Используем предварительно подписанный URL-адрес для загрузки файла в объектное хранилище непосредственно с клиентской стороны. Это осуществляется посредством PUT-запроса, где файл является телом запроса.
После загрузки файла объектное хранилище отправит уведомление на наш бэкенд с помощью S3 Notifications. Затем наш бэкенд обновит метаданные файла в нашей базе данных, присвоив ему статус "uploaded".

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

2. Пользователи могут скачать файл с любого устройства

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

Плохое решение: Скачивание через наш сервер

Подход

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

Проблемы

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

Хорошее решение: Скачивание c объектного хранилища

Подход

Более оптимальный подход - позволить пользователю скачать файл непосредственно из объектного хранилища, с помощью предварительно подписанного URL-адреса. Как и при загрузке файлов, предварительно подписанный URL-адрес предоставит пользователю разрешение на загрузку файла из определенного места в объектном хранилище в течение ограниченного времени.

Запрос предварительно подписанного URL-адреса для скачивания файла.

GET /files/{fileId}/presigned-url -> PresignedUrl

Используем предварительно подписанный URL-адрес для скачивания файла из объектного хранилища непосредственно на клиентское устройство.

Проблемы

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

Отличное решение: Скачивание c CDN

Подход

Наилучший подход - использование сети доставки контента (Content Delivery Network, CDN) для кэширования файла ближе к пользователю. CDN - это сеть серверов, распределенных по всему миру, которые кэшируют файлы и предоставляют их пользователям с ближайшего к ним сервера. Это уменьшает задержку и ускоряет время загрузки.

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

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

Проблемы

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

3. Пользователи могут делиться файлами с другими пользователями

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

Главный вопрос на собеседовании здесь - как сделать этот процесс быстрым и эффективным. Давайте разберемся.

Плохое решение: Список доступа в метаданных

Подход

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

{
  "id": "12",
  "name": "file.txt",
  "size": 2000,
  "mime_type": "text/plain",
  "uploaded_by": "user1",
  "sharelist": ["user2", "user3"]
}

Проблемы

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

Хорошее решение: Кеширование списка доступа

Подход

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

Наша запись в кэше будет представлять собой простую пару ключ-значение, примерно такую:

user1:["file1", "file2"]

Проблемы

Нам необходимо синхронизировать список sharedFiles со списком sharelist в метаданных файла. Лучший способ решить эту проблему - хранить сопоставление пользователей и файлов в той же базе данных и обновлять как sharelist, так и sharedFiles в рамках одной транзакции.

Отличное решение: Отдельная таблица для списка доступа

Подход

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

Новая таблица SharedFiles будет выглядеть следующим образом:

| user_id (PK) | file_id (SK) |
|--------------|--------------|
| user1        | file1        |
| user1        | file2        |
| user2        | file3        |

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

Проблемы

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

4. Файлы синхронизируются между устройствами

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

Локально -> Удаленно
Удаленно -> Локально

Локально -> Удаленно

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

Для этого нам нужен агент синхронизации на стороне клиента, который:

Отслеживает изменения в локальной папке Dropbox, используя события файловой системы, специфичные для операционной системы (например, FileSystemWatcher в Windows или FSEvents в macOS).
При обнаружении изменений агент ставит измененный файл в очередь на отправку.
Затем агент использует наш API для загрузки файлов, чтобы отправить изменения на сервер вместе с обновленными метаданными.
Конфликты разрешаются с использованием стратегии "последняя запись побеждает" - это означает, что если два пользователя редактируют один и тот же файл, будет сохранена последняя внесенная ими правка.

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

Удаленно -> Локально

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

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

Опрос (Polling): клиент периодически спрашивает у сервера: "Что-нибудь изменилось с момента последней синхронизации?" Сервер обращается к базе данных, чтобы проверить, есть ли у каких-либо файлов, за которыми следит пользователь, метка времени updated_at, более новая, чем время последней синхронизации. Это простой метод, но он может медленно обнаруживать изменения и расходовать ресурсы, если ничего не изменилось.
WebSocket или SSE: сервер поддерживает открытое соединение с каждым клиентом и отправляет уведомления при возникновении изменений. Это более сложный подход, но он обеспечивает обновления в режиме реального времени.

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

Новые файлы: файлы, которые были недавно отредактированы (в течение последних нескольких часов). Для них мы поддерживаем соединение WebSocket, чтобы обеспечить синхронизацию практически в реальном времени.

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

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

Итоговый дизайн

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

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

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

Балансировщик нагрузки и API-шлюз: отвечает за маршрутизацию запросов к соответствующему серверу и обработку таких операций, как завершение SSL-соединения, ограничение скорости и проверка запросов.

Файловый сервис: отвечает за запись в базу данных метаданных файлов, а также за генерацию предварительно подписанных URL-адресов с использованием SDK S3. Он фактически не обрабатывает загрузку или скачивание файлов. Это всего лишь посредник между клиентом и S3.

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

S3: здесь фактически хранятся файлы. Мы загружаем и скачиваем файлы напрямую в S3 и из S3, используя предварительно подписанные URL-адреса, которые получаем от файлового сервера.

CDN: кэширует файлы вблизи пользователя для уменьшения задержки.

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

1. Как поддержать большие файлы?

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

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

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

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

Таймауты: веб-серверы и клиенты обычно имеют настройки таймаутов, чтобы предотвратить бесконечное ожидание ответа. Один POST запрос с файлом размером 50 ГБ может легко превысить эти таймауты. На самом деле, это может быть подходящим моментом для быстрых подсчетов на собеседовании. Если у нас есть файл размером 50 ГБ и интернет-соединение со скоростью 100 Мбит/с, сколько времени потребуется для загрузки файла? 50 ГБ * 8 бит/байт / 100 Мбит/с = 4000 секунд, тогда 4000 секунд / 60 секунд/минута / 60 минут/час = 1,11 часа. Это очень долгое время ожидания без ответа от сервера.
Ограничения браузера и сервера: в большинстве случаев загрузка файла размером 50 ГБ с помощью одного POST запроса невозможна в принципе из-за ограничений, которые браузеры и веб-серверы часто устанавливают на размер тела запроса. Хотя веб-серверы, такие как Apache и NGINX, могут быть настроены на прием больших объемов данных, большинство современных сервисов, таких как Amazon API Gateway, имеют жесткие ограничения, которые намного ниже и не могут быть увеличены. В случае с Amazon API Gateway, это всего 10 МБ.
Сетевые сбои: большие файлы более подвержены сетевым сбоям. Если пользователь загружает файл размером 50 ГБ, и его интернет-соединение обрывается, ему придется начинать загрузку заново.
Пользовательский опыт: пользователи фактически не видят хода загрузки. Они понятия не имеют, сколько времени это займет или идет ли вообще процесс.

Для решения этих проблем мы можем использовать метод, называемый "разбивкой на части" (chunking), чтобы разбить файл на более мелкие фрагменты и загружать их по одному (или параллельно, в зависимости от пропускной способности сети). Распространенная ошибка, которую допускают кандидаты, - это разбивка файла на части на сервере, в чем фактически нет смысла, поскольку для этого все равно загружается весь файл целиком. Поэтому разбивка должна выполняться на стороне клиента. Обычно мы разбиваем файл на фрагменты размером 5-10 МБ, но это можно скорректировать в зависимости от условий сети и размера файла.

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

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

{
  "id": "12",
  "name": "file.txt",
  "size": 2000,
  "mimeType": "text/plain",
  "uploadedBy": "user1",
  "status": "uploading",
  "chunks": [
    {
      "id": "chunk1",
      "status": "uploaded"
    },
    {
      "id": "chunk2",
      "status": "uploading"
    },
    {
      "id": "chunk3",
      "status": "not-uploaded"
    }
  ]
}

Когда пользователь возобновляет загрузку, мы можем проверить поле "chunks", чтобы увидеть, какие фрагменты уже загружены, а какие нет. Затем мы можем начать загрузку тех фрагментов, которые еще не были загружены. Таким образом, пользователю не придется начинать загрузку заново, если он потеряет интернет-соединение или закроет браузер.

Но как нам обеспечить синхронизацию поля chunks с фактически загруженными фрагментами файла?

Мы можем использовать два подхода:

Хорошее решение: Обновление через PATCH запрос

Подход

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

Клиент берет файл, разбивает его на фрагменты и загружает эти фрагменты непосредственно в S3.
S3 отправляет сообщение об успешной загрузке каждого фрагмента.
В случае успеха клиент отправляет PATCH запрос на наш бэкенд для обновления поля chunks в таблице FileMetadata.

PATCH /files/{fileId}/chunks
{
  "chunks": [
    {
      "id": "chunk1",
      "status": "uploaded"
    },
  ]
}

Проблемы

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

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

Подход

Более эффективным подходом является реализация серверной проверки загрузки фрагментов с использованием ETags. Уведомления о событиях S3 не срабатывают для отдельных фрагментов загрузки, a только когда весь объект завершен. Поэтому нам необходимо использовать непосредственно API многокомпонентной загрузки S3 (S3 Multipart Upload API).

Каждый фрагмент получает ETag после успешной загрузки, который клиент может включить в PATCH запрос к нашему бэкенду. Затем наш бэкенд может проверить эти ETag, вызвав ListParts API в S3, что обеспечивает эффективный способ проверки нескольких фрагментов одновременно. Такой подход обеспечивает баланс между удобством использования и целостностью данных - мы принимаем обновления от
клиента для отслеживания прогресса в реальном времени, чтобы предоставлять немедленную обратную связь, но периодически проверяем статус фрагмента на стороне сервера, прежде чем пометить весь файл как "uploaded".

Доверяй, но проверяй.

Далее поговорим о том, как однозначно идентифицировать файл и его фрагмент. Когда вы пытаетесь возобновить загрузку, первый вопрос, который следует задать, это: (1) Пытались ли мы загрузить этот файл раньше? и (2) Если да, то какие фрагменты уже загружены? Чтобы ответить на первый вопрос, мы не можем наивно полагаться на имя файла. Это связано с тем, что два разных пользователя (или
даже один и тот же пользователь) могут загружать файлы с одинаковым именем. Вместо этого нам нужно полагаться на уникальный идентификатор, полученный из содержимого файла. Это называется отпечатком (fingerprint).

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

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

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

Клиент разбивает файл на части размером 5-10 МБ и вычисляет отпечаток для каждой части. Он также вычисляет отпечаток для всего файла, который станет идентификатором файла (fileId).
Клиент отправляет GET запрос для получения FileMetadata с заданным fileId(отпечатком), чтобы проверить, существует ли он уже - в этом случае мы сможем возобновить загрузку.
Если файл не существует, клиент отправляет POST запрос для инициирования загрузки (multipart upload). Бэкенд вызывает S3 API CreateMultipartUpload, чтобы получить uploadId, генерирует предварительно подписанные URL-адреса для каждой части, сохраняет метаданные файла в таблице FileMetadata со статусом "uploading" и возвращает uploadId вместе с предварительно подписанными URL-адресами для каждого фрагмента.
Затем клиент загружает каждый фрагмент в S3, используя соответствующий предварительно подписанный URL-адрес (для каждой части требуется свой собственный предварительно подписанный URL-адрес с идентификатором загрузки uploadId и номером части partNumber). После загрузки каждого фрагмента клиент отправляет PATCH запрос в наш бэкенд со статусом фрагмента и ETag. Затем наш бэкенд может проверить загрузку фрагментов с помощью S3 API ListParts, прежде чем обновить поле chunks в таблице FileMetadata, и помечает фрагмент как "uploaded".
Как только все фрагменты в нашем массиве фрагментов будут помечены как "uploaded", бэкенд обновляет таблицу FileMetadata и помечает весь файл как "uploaded".

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

Описанный нами подход не нов, на самом деле, эта проблема уже
решена поставщиками облачных хранилищ, такими как Amazon S3. У
них есть функция Multipart Upload,
которая позволяет загружать большие объекты по частям. Это именно
то, что мы только что описали. Клиент разбивает файл на части и
загружает каждую часть в S3. Затем S3 объединяет части в один
объект. Они даже предоставляют удобный JavaScript
SDK,
который будет обрабатывать всю разбивку на части и загрузку за
вас.

При загрузке нескольких частей в S3 уведомления о событиях
срабатывают только после завершения всей загрузки (когда все
части собраны), а не при загрузке отдельных частей. Для
отслеживания прогресса загрузки отдельных частей необходимо
использовать API ListParts в S3, который возвращает все
загруженные части с их ETags для текущей загрузки.

На практике вы будете полагаться на этот API при проектировании
таких систем, как Dropbox. Однако, скорее всего, на собеседовании
вы не сможете просто сказать: "Я бы использовал S3 Multipart
Upload API", не сумев объяснить, как он работает и как бы вы сами
его реализовали, если бы это потребовалось. Тем не менее,
сообщить интервьюеру о том что вы знаете про существующее готовое
решение - хорошая идея, поскольку это демонстрирует практический
опыт.

2. Как можно максимально ускорить загрузку, скачивание и синхронизацию данных?

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

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

Однако нам нужно разумно подходить к вопросу сжатия. Сжатие полезно только в том случае, если выигрыш в скорости от передачи меньшего количества байтов перевешивает время, необходимое для сжатия и распаковки файла. Для некоторых типов файлов, особенно медиафайлов, таких как изображения и видео, коэффициент сжатия настолько низок, что время, затрачиваемое на сжатие и распаковку файла, не оправдывает себя. Если вы прямо сейчас возьмете файл .png и сожмете его, вам повезет, если размер файла уменьшится более чем на несколько процентов - поэтому это не стоит того. С другой стороны, для текстовых файлов коэффициент сжатия намного выше, и в зависимости от условий сети это вполне может быть выгодно. Текстовый файл размером 5 ГБ может быть сжат до 1 ГБ или даже меньше в зависимости от содержимого.

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

Алгоритмы сжатия

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

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

3. Как можно обеспечить безопасность файлов?

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

Шифрование при передаче: конечно, для большинства кандидатов это очевидно. Мы должны использовать HTTPS для шифрования данных при их передаче между клиентом и сервером. Это стандартная практика, поддерживаемая всеми современными браузерами.
Шифрование при хранении: мы также должны шифровать файлы, когда они хранятся в S3. Это встроенная функция S3, и ее легко включить. Когда файл загружается в S3, мы можем указать, что он должен быть зашифрован. Затем S3 шифрует файл с помощью уникального ключа и сохранит ключ отдельно от файла. Таким образом, даже если кто-то получит доступ к файлу, он не сможет расшифровать его без ключа. Подробнее о шифровании в S3 можно узнать здесь.
Контроль доступа: наш список общего доступа (sharelist) или отдельная таблица/кэш общего доступа - это наш базовый ACL (Access Control List, список контроля доступа). Как обсуждалось ранее, мы гарантируем, что предоставляем ссылки для скачивания только авторизованным пользователям.

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

Здесь снова вступают в игру подписанные URL-адреса, о которых мы говорили ранее. Когда пользователь запрашивает ссылку для скачивания, мы генерируем подписанный URL-адрес, действительный только в течение короткого периода времени (например, 5 минут). Затем этот подписанный URL-адрес отправляется пользователю, который
может использовать его для загрузки файла. Стоит отметить, что подписанные URL-адреса являются токенами "на предъявителя" (bearer token) - любой, у кого есть действительный, непросроченный URL-адрес, может загрузить файл. Короткий срок действия ограничивает уязвимость, но не полностью предотвращает распространение. Для более строгих сценариев безопасности можно добавить дополнительные ограничения, такие как привязка к IP-адресу, или потребовать
использования подписанного URL-адреса в сочетании с аутентификационными файлами cookie.

Подписанные URL-адреса также работают с современными CDN, такими как CloudFront, и являются функцией S3. Вот как это работает:

Генерация: на сервере генерируется подписанный URL-адрес, включающий подпись, которая обычно содержит путь к URL-адресу, метку времени истечения срока действия и, возможно, другие ограничения (например, IP-адрес). В случае CloudFront эта подпись создается с использованием закрытого ключа поставщика контента.
Распространение: подписанный URL-адрес распространяется авторизованному пользователю, который может использовать его для прямого доступа к указанному ресурсу из CDN.
Проверка подписи: когда CDN получает запрос с подписанным URL-адресом, он проверяет подпись, используя соответствующий открытый ключ (зарегистрированный в CloudFront), проверяет метку времени истечения срока действия и любые другие ограничения. Если подпись действительна и срок действия URL-адреса не истек, CDN предоставляет запрошенный контент. В противном случае доступ запрещается.

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

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

Middle

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

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

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

Задача Dropbox: от Middle кандидата ожидается четко определенный API и модель данных, а также высокоуровневый дизайн, который функционально покрывает все процессы загрузки, скачивания и обмена файлами. Не ожидается, что кандидаты сразу будут знать о предварительно подписанных URL-адресах или о прямой загрузке/скачке в/из S3, или сразу предложат разбиение на части. Однако после
уточняющих вопросов, таких как: "Вы сейчас загружаете файл дважды, как этого избежать?" или "Как можно показать прогресс пользователя, позволяя ему возобновить загрузку?", они смогут проанализировать проблему и прийти к решению коммуницируя с интервьюером.

Senior

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

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

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

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

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

Staff+

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

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

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

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

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

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

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

NowInterview — Thu, 30 Apr 2026 17:01:24 +0000

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

Больше статей и разборов по System Design: https://nowinterview.ru

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

❤️ Что такое Tinder?

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

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

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

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

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

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

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

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

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

Система должна обеспечивать сильную согласованность (strong consistency) для свайпов. Если пользователь свайпнул "да" на человека, который уже свайпнул "да" на него, оба должны получить уведомление о матче.
Система должна масштабироваться под большое количество ежедневных активных / одновременных пользователей (20 млн DAU, в среднем ~100 свайпов на пользователя в день).
Система должна быстро формировать список потенциальных матчей (< 300 мс).
Система не показывает повторно профили, по которым пользователь уже свайпал.

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

Система должна предотвращать использование фейковых профилей.

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

Подготовка

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

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

Для Tinder основные сущности довольно очевидны:

User: это и пользователь приложения, и профиль, который показывают другим пользователям.
Swipe: выражение "да" или "нет" по отношению к профилю другого пользователя. Содержит информацию о пользователе, который свайпает (swiping_user), и пользователе, которого свайпают (target_user).
Match: связь между двумя пользователями, возникающая в результате взаимного свайпа "да".

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

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

POST /profile
{
  min_age,
  max_age,
  max_distance,
  interested_in: "female" | "male",
  ...
}

Далее нужен эндпоинт, который возвращает "ленту" профилей потенциальных кандидатов.

GET /feed?lat={}&long={} -> User[]

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

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

Также нужен эндпоинт для свайпа:

POST /swipe/{userId}
{
  "decision": "yes" | "no"
}

В каждом из этих запросов информация о пользователе передается в
заголовках (через session token или auth token). Это
распространенный паттерн, так мы можем обеспечивать
аутентификацию/авторизацию и безопасность. Не стоит передавать
пользовательские данные в теле запроса: в этом случае их можно
легко подделать.

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

1. Пользователи могут создать профиль с предпочтениями и указать максимальную дистанцию

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

Мы принимаем запрос POST /profile и сохраняем настройки в базе. Для старта нам достаточно простой архитектуры Клиент -> Сервер -> База данных. При этом, если сразу очевидно, что мы будем использовать несколько сервисов, то можно сразу добавить на схему API Gateway для маршрутизации запросов.

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

Когда пользователь создает профиль:

Клиент отправляет POST /profile с данными профиля в теле запроса.
API Gateway направляет запрос в сервис профилей.
Сервис профилей обновляет предпочтения пользователя в базе.
Результат возвращается клиенту.

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

Когда пользователь открывает приложение, он сразу видит список профилей для свайпа. Эти профили должны соответствовать фильтрам (возраст, интересы и т. п.), а также географии пользователя (например "< 2 км", "< 5 км", "< 15 км").

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

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

Простейший запрос мог бы выглядеть так:

SELECT * FROM users
WHERE age BETWEEN preferredAgeMin AND preferredAgeMax
AND gender = preferredInterestedIn
AND lat BETWEEN userLat - preferredDistance AND userLat + preferredDistance
AND long BETWEEN userLong - preferredDistance AND userLong + preferredDistance

Когда пользователь запрашивает новый набор профилей:

Клиент отправляет GET /feed, передавая текущую локацию через query‑параметры.
API Gateway направляет запрос в сервис профилей.
Сервис профилей запрашивает базу данных, выбирая пользователей по предпочтениям и локации.
Результаты возвращаются клиенту.

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

3. Пользователи могут свайпать вправо/влево и выражать да/нет по отношению к другим пользователям

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

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

Добавим два новых компонента:

Сервис свайпов: сохраняет свайпы и проверяет матчи.
Хранилище свайпов: хранит данные свайпов.

Почему мы выбрали отдельный сервис и отдельное хранилище?

Обоснование: создание/обновление профиля происходят существенно
реже, чем запись свайпов. Разделив сервисы, мы можем независимо
масштабировать сервис свайпов. Аналогично, по данным, свайпов
будет очень много. При 20 млн DAU × 100 свайпов/день × ~100 байт на свайп получается порядка ~200GB данных в день. Такой
объем и нагрузку хорошо сможет обработать хранилище
оптимизированное для записи такое как Cassandra (которое может
быть не лучшим выбором для профилей). Кроме того, отдельное
хранилище позволяет оптимизировать паттерны доступа и кэширование
для свайпов без влияния на сервис профилей.

Такое разделение - не универсальный ответ для всех систем. Но
здесь плюсы перевешивают минусы.

Поскольку свайп - действие почти без усилий, можно ожидать большой поток записей. Если принять 20 млн DAU и в среднем 100 свайпов/день, это 2 млрд записей в день. Это почти наверняка означает, что данные нужно партиционировать.

Cassandra хорошо подходит как хранилище свайпов. Мы можем партиционировать по swiping_user_id. Тогда проверка "свайпал ли пользователь A пользователя B" будет быстрой: мы предсказуемо идем в один раздел (partition). Также Cassandra хорошо выдерживает большие объемы записей благодаря архитектуре своего хранения (CommitLog + Memtables + SSTables). Недостатком использования Cassandra здесь является конечная согласованность для данных о свайпах. Мы обсудим способы нивелировать этот недостаток когда будем погружаться в детали.

Когда пользователь свайпает:

Клиент отправляет POST /swipe/{userId} с userId профиля и результатом свайпа (вправо/влево).
API Gateway направляет запрос в сервис свайпов.
Сервис свайпов записывает свайп в хранилище свайпов.
Сервис свайпов проверяет наличие обратного свайпа и, если он есть, сообщает клиенту о матче.

4. Пользователи получают уведомление о матче при взаимном свайпе

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

Уведомить Боба просто: это мы уже делаем. Поскольку он - второй, сразу после свайпа вправо мы проверяем, лайкнула ли Алиса, и если да - показываем уведомление на устройстве Боба.

Но что насчет Алисы? Она могла свайпнуть Боба несколькими днями ранее. Нам нужно отправить push‑уведомление на устройство Алисы, сообщив, что у нее новый матч.

Для этого будем использовать нативные сервисы push-уведомлений, такие как Apple Push Notification Service (APNS) или Firebase Cloud Messaging (FCM).

APNS и FCM - это службы push‑уведомлений, с собственным набором
API и SDK, которые мы можем использовать для отправки
push‑уведомлений на пользовательские устройства.

Кратко повторим полный процесс свайпа с учетом пушей:

Некоторое время назад Алиса свайпнула вправо Боба, и мы сохранили это в хранилище свайпов.
Боб свайпает вправо Алису.
Сервер проверяет наличие обратного свайпа и находит его.
Мы показываем уведомление о матче на устройстве Боба сразу после свайпа.
Мы отправляем push‑уведомление через APNS/FCM Алисе, что у нее новый матч.

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

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

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

1. Как обеспечить согласованность и низкую задержку при свайпах?

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

Свайп Алисы приходит на сервер - мы проверяем обратный свайп. Его нет.
Свайп Боба приходит на сервер - мы проверяем обратный свайп. Его нет.
Мы сохраняем свайп Алисы на Боба.
Мы сохраняем свайп Боба на Алису.

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

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

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

Хорошее решение: Транзакции

Подход

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

В Cassandra есть базовая поддержка того, что они называют легковесные транзакции (Lightweight Transactions, LWT), но это не полноценные ACID‑транзакции. LWT используют консенсусный протокол Paxos для обеспечения линеаризуемой согласованности (linearizable consistency) для конкретных операций, но только в рамках одного раздела (partition). Между разделами они не дают атомарности,
уровней изоляции и откатов. Также LWT имеют существенные накладные расходы из‑за нескольких сетевых коммуникаций (round-trips) между нодами. Это делает такие транзакции подходящими в основном для простых условных обновлений.

Проблемы

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

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

Отличное решение: Транзакции в одном разделе

Подход

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

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

CREATE TABLE swipes (
    user_pair text,      -- ключ партиционирования: smaller_id:larger_id
    from_user uuid,      -- кластерный ключ
    to_user uuid,        -- кластерный ключ
    direction text,
    created_at timestamp,
    PRIMARY KEY ((user_pair), from_user, to_user)
);

При свайпе формируем user_pair, отсортировав id, для обеспечения согласованности:

def get_user_pair(user_a, user_b):
    # Отсортируем id так, чтобы (A->B) и (B->A) были в одном разделе
    sorted_ids = sorted([user_a, user_b])
    return f"{sorted_ids[0]}:{sorted_ids[1]}"

def handle_swipe(from_user, to_user, direction):
    user_pair = get_user_pair(from_user, to_user)

    # Обе операции выполняются атомарно в одном разделе
    batch = """
    BEGIN BATCH
        INSERT INTO swipes (user_pair, from_user, to_user, direction, created_at)
        VALUES (?, ?, ?, ?, ?);

        SELECT direction FROM swipes
        WHERE user_pair = ?
        AND from_user = ?
        AND to_user = ?;
    APPLY BATCH;
    """

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

Проблемы

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

Отличное решение: Redis для атомарных операций

Подход

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

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

Структура ключа и значения:

Key: "swipes:123:456"
Value: {
  "123_swipe": "yes",
  "456_swipe": "no"
}

def get_key(user_a, user_b):
    # Отсортируем id так, чтобы (A->B) и (B->A) были в одном разделе
    sorted_ids = sorted([user_a, user_b])
    return f"swipes:{sorted_ids[0]}:{sorted_ids[1]}"

def handle_swipe(from_user, to_user, direction):
    key = get_key(from_user, to_user)

    # Используем Redis хеш для хранения свайпов обоих пользователей
    # Хеш имеет два поля: user1_swipe и user2_swipe
    script = """
    redis.call('HSET', KEYS[1], ARGV[1], ARGV[2])
    return redis.call('HGET', KEYS[1], ARGV[3])
    """

    # Выполняем атомарно используя Lua скрипт
    other_swipe = redis.eval(
        script,
        keys=[key],
        args=[
            f"{from_user}_swipe",  # поле для установки
            direction,             # наш свайп
            f"{to_user}_swipe"     # поле для проверки
        ]
    ) # Возвращает значение другого пользователя

    # Если другой пользователь тоже свайпнул вправо, это матч!
    if direction == 'right' and other_swipe == 'right':
        create_match(from_user, to_user)

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

Проблемы

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

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

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

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

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

В высокоуровневом дизайне мы делали медленный запрос каждый раз, когда нужно сгенерировать новый список:

SELECT * FROM users
WHERE age BETWEEN preferredAgeMin AND preferredAgeMax
AND gender = preferredInterestedIn
AND lat BETWEEN userLat - preferredDistance AND userLat + preferredDistance
AND long BETWEEN userLong - preferredDistance AND userLong + preferredDistance

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

Хорошее решение: Индексированные БД для real-time запросов

Подход

Один из способов добиться низкой задержки - использовать индексированные БД для запросов реального времени. Если создать индексы по полям, используемым при построении списка (предпочтения, возраст, и особенно geo‑данные), можно сильно ускорить время ответа. Геопространственный индекс позволяет эффективно находить
пользователей в заданной области.

Для масштабируемости и требований Tinder можно использовать БД оптимизированную для поиска вроде Elasticsearch или OpenSearch. Они заточены под быстрый поиск и сложные запросы, что делает их пригодными для обработки больших объемов данных с минимальной задержкой.

Проблемы

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

Обычно это решают через механизм Change Data Capture (CDC). Это шаблон, который фиксирует изменения базы данных (вставки, обновления, удаления) и передает их в другие системы. Часто реализуется путем мониторинга журнала упреждающей записи
(write-ahead log) базы данных.

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

Хорошее решение: Предварительные вычисления и кэширование

Подход

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

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

Проблемы

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

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

Отличное решение: Комбинация предвычислений и индексированной БД

Подход

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

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

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

Как мы можем решить проблему устаревших списков?

Кэширование списков пользователей может привести к тому, что мы будем предлагать "устаревшие" профили:

пользователь, предложенный в списке, возможно, изменил местоположение и больше не находится достаточно близко, чтобы соответствовать критериям фильтра
пользователь, предложенный в ленте, может изменить свой профиль (например, интересы) и больше не соответствует критериям фильтра

Чтобы смягчить эту проблему, можно:

поставить строгий TTL на кэш списков (например, < 1 часа) и пересчитывать по расписанию
предвычислять списки только для действительно активных пользователей, а не для всех

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

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

Также есть вполне определенные пользовательские действия, которые делают кэш устаревшим:

пользователь поменял фильтры - профили в кэше больше не релевантны
пользователь значительно изменил местоположение (например, переехал в другой район/город) - кэш больше не соответствует фильтру "поблизости"

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

3. Как избежать повторного показа профилей, по которым пользователь уже свайпал?

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

Плохое решение: Запрос в хранилище свайпов

Подход

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

Проблемы

С этим подходом есть две проблемы:

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

Отличное решение: Кэш + запрос в хранилище свайпов

Подход

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

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

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

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

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

Проблемы

Остается проблема пользователей с очень большой историей свайпов: проверка на contains по большому множеству id будет все медленнее по мере роста истории.

Отличное решение: Кэш + запрос в хранилище свайпов + фильтр Блума

Подход

Этот подход может выглядеть слегка "over-engineered", но это
вполне разумный сценарий для фильтра Блума: поддержать построение
списка для пользователей с огромной историей свайпов.

Если история свайпов превышает определенный порог (когда проверка на contains становится дорогой), мы строим и кэшируем фильтр Блума и используем его для фильтрации.

Фильтр Блума иногда дает ложноположительные результаты (false positives) (например, что профиль уже свайпали, хотя это не так), но никогда не дает ложноотрицательные (false negatives) (например, что профиль не свайпали, если его свайпали). Значит мы точно избегаем повторных показов, но можем не показать пользователю небольшое количество профилей из-за ложноположительных результатов.

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

Проблемы

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

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

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

Middle

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

Senior

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

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

Staff+

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

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

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

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

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

Больше статей и разборов по System Design: https://nowinterview.ru

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

🚗 Что такое Uber?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подготовка

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

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

Проектирование 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

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

Senior

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

Staff+

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

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

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

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

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

Больше статей и разборов по System Design: https://nowinterview.ru

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

🎟️ Что такое 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+

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