Comments 6
Мы в одном из продуктов применяем похожую схему. Не в таких масштабах, правда.
Много всего напихано... Им уже давно нужно переходить на стриминговые базы, но они всё делают свои самокаты, нагромождая и усложняя архитектуру. Очевидно что в компании на основных позициях сидят деды со старым виженом и на старых технологиях.
У нас бы в бинанс таких уволили.
Зачем им 40 миллионов запросов в секунду?
Заказ такси не могут одновременно делать миллионы человек, потому что населения на земле для таких масштабов не хватит.
Значит система явно перегружена внутренними коммуникациями. Но что это за коммуникации? Ответ прост - микросервисы. Вместо пусть миллиона в секунду (и то много) имеем на пару порядков больше.
Для транснациональных компаний как Uber очевидно напрашивается решение с разделением данных на регионы, так как нет никакой надобности хранить локальную OLTP инфу в единой базе, а сливать данные воедино уже в OLAP базу. Ведь очевидно же что клиенты из одного региона запрашивают 99.99% инфы из этого же региона?
Ну типа промежуточный диспетчер обрабатывает запрос и направляет его в локальный сервис либо в сервис другого региона, при надобности, что сразу распределит нагрузку.
Потому скорее было бы интересно не только реализация описанная в статье, но и причины такой централизации децентрализованных данных. Т.е. зачем было создавать сложности?
Как Uber обслуживает более 40 миллионов чтений в секунду из онлайн-хранилища с помощью встроенного кэша