Система заказа поездок

Этот кейс показывает ядро сервиса поездок: поток координат водителей, поиск кандидатов, конкурентное резервирование, жизненный цикл поездки и восстановление платежа. Числа ниже — явные проектные допущения, а не публичные метрики конкретной компании.

Нагрузка и расчёты

Допустим:

• 1 млн водителей одновременно онлайн;
• одна координата каждые 4 секунды;
• 10 млн поездок в сутки;
• около 5 КБ основной записи и событий на поездку.

Получаем 1 000 000 / 4 = 250 000 координат в секунду. Для поездок средняя частота равна примерно 116 новым поездкам в секунду; пик проектируется отдельно. Хранение поездок без индексов, реплик и служебных данных: 10 млн × 5 КБ = 50 ГБ в сутки, или около 18,25 ТБ в год. Оценка Redis на одного водителя должна измеряться на выбранной версии и конфигурации: payload и реальный расход памяти с allocator, индексами и репликацией — разные величины.

Почему два контура состояния

Redis GEO держит оперативную позицию и доступность, чтобы быстро выполнить GEOSEARCH по радиусу. GEOADD обновляет координату существующего member. Durable Location Log получает последнюю принятую координату каждого активного водителя в батче. Нельзя сохранять только водителей, сменивших геоячейку: координата внутри прежней ячейки тоже меняется и нужна для восстановления.

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