Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Создание рейтинга сложности пеших маршрутов по данным о высоте
Одно лишь расстояние плохо отражает, насколько тяжёл поход на самом деле. Ровная тропа длиной шесть миль вдоль берега реки и шестимильная тропа с подъёмом на гору в каталоге приложения-путеводителя значились под одной и той же меткой «средняя, шесть миль». Такая классификация порождала постоянный поток жалоб от туристов, которые доверились средней сложности и оказались на гораздо более тяжёлом подъёме, чем были готовы.
Приложение уже хранило каждую тропу как последовательность координат, описывающую её путь, собранную из GPS-записей, присланных участниками. Не хватало высоты вдоль этого пути, то есть именно тех данных, которые отличают ровную прогулку от серьёзного подъёма при одинаковом расстоянии. /v1/elevation принимал полный список координат тропы, поскольку пакетный запрос принимает список точек и возвращает высоту для каждой, и приложение получало значение высоты для каждой точки записанного пути в том же порядке, в каком они были отправлены.
По этому списку вычислить суммарный набор высоты, то есть сумму всех подъёмов вдоль маршрута, было простой арифметикой, которую выполнял сервер самого приложения. Суммарный набор высоты вместе с расстоянием давал гораздо более полезный показатель сложности, чем одно расстояние: тропа с большим набором высоты на коротком отрезке оценивалась как крутая и сложная, как бы коротко она ни выглядела на бумаге, а длинная ровная тропа оценивалась как более лёгкая, несмотря на длину. Это гораздо точнее соответствовало тому, что туристы реально ощущают на местности, чем прежняя система, учитывавшая только расстояние.
Приложение перестроило рейтинг сложности вокруг этого совмещённого показателя и задним числом пересчитало все тропы, уже бывшие в каталоге, одним разовым пакетным заданием по всей библиотеке маршрутов. Этот пакет стал самым крупным запросом, который приложение когда-либо отправляло, и поскольку в пакетном запросе высоты одной оплачиваемой позицией считается каждая точка, а не каждая тропа, точный объём задания зависел от числа точек координат во всей библиотеке, а не от числа троп. Команда учла это, оценивая стоимость заранее, а не удивляясь ей потом.
Помимо главного рейтинга сложности, те же данные о высоте позволили приложению показывать на странице каждой тропы график подъёмов, похожий на тот, что показывает велосипедное приложение. Турист видел, где именно на маршруте находятся крутые участки, а не только общую метку сложности. Тем, кто хотел подготовиться к конкретному тяжёлому отрезку, а не просто знать, что тропа в целом сложная, график оказался полезнее одной метки.
После первоначального пакета дальнейшие запросы высоты определялись новыми присланными тропами. Это гораздо меньший и более равномерный объём, чем разовый пересчёт, и при обычном темпе поступления новых троп от участников он с запасом укладывался в бесплатную дневную квоту.
Система рейтинга хороша ровно настолько, насколько хороши данные в её основе, и высота оказалась тем недостающим входным параметром, который всё это время был нужен рейтингу сложности приложения. Документация по эндпоинту, включая ограничения на число точек в запросе, находится по адресу /docs/elevation-lookup/.