System design нового сервиса Яндекс Автобус
SRO приходит с запросом: «Давайте быстро запустим Яндекс Автобус — поиск рейсов между А и Б на дату, список рейсов, выбор места, переход на сайт партнёра для покупки».
Дано:
- вход: точка А, точка Б, дата;
- три поставщика билетов, у каждого свой HTTP API;
- наша задача — агрегировать, показать, отдать пользователя партнёру.
Вопросы
- Как выглядит верхнеуровневая архитектура агрегатора?
- Что делать, если поставщик упал или отвечает медленно?
- Как решать проблему разных названий остановок у разных поставщиков?
- Как снизить нагрузку — свою и на поставщиков?
- Что делать при большом трафике или пустом кэше?
Подсказки
Подсказка про архитектуру
Представь путь одного пользовательского запроса от момента нажатия «Найти» до появления первого рейса на экране. Какие системы участвуют в этом пути и какие из них находятся под нашим контролем, а какие — нет?
Подсказка про поставщиков
Пользователь нажал «Найти». Один партнёр уже вернул 20 рейсов, второй пока отвечает, третий вообще завис. Какой результат пользователь должен видеть через первую секунду?
Подсказка про упавщего поставщика
Понедельник, 9 утра, кэш только что сбросили. Десять тысяч человек одновременно ищут МосПользователь увидел рейс за 1 500 ₽, но именно в момент выбора места поставщик недоступен. Что ты можешь гарантировать пользователю, а что — нет?ква → Тула. Сколько запросов уйдёт поставщику?
Подсказка про разные названия остановок
Пользователь ищет «Москва → Тула». У одного поставщика остановка называется «Москва, автостанция Новоясеневская», у другого — «Москва (Южные ворота)». Это одна и та же точка для нашей системы или разные? что увидит пользователь в момент, когда один поставщик отвалился.