Новогодний переполох X Яндекс Доставка

[dyadyaSerezha]

Крайне сумбурный и неясный текст.

Что значит X в заголовке? Почему всё в именительном падеже? Заголовок статьи это не список тэгов, если что.

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

Узнал на днях, значит, автор не имел к этому прямого отношения. Но в конце статьи - "я сэкономил компании". Не имел отношения, но сэкономил? А если имел, почему узнал только что? Непонятно.

Кейс стрелял? В каком смысле? Непонятно.

Какую линию обороны? Кто от кого и как оборорялся? Непонятно.

Кто такие мы, которые готовы, но нет? Яндекс? Клиенты? Sunlight? Городские службы? Непонятно.

И так далее...

Решение: Создание заказа после сборки заказа торговой точкой -> Создание заказа в Яндексе сразу после оплаты заказа. Дополнительная проверка на кнопке "Оплатить"

Это как было и как стало? (опять приходится гадать). Если да, то вообще непонятно, почему заказ создавался только после сборки заказа. Тут вообще смешно - собирается то, чего ещё нет.

Ну и в целом - довольно просто, кажется, иметь индикатор на бэкенде, насколько быстро меняется цена доставки, и выполнять дополнительную проверку на этапе оплаты, только если если этот индикатор включён. Это если дополнительная проверка медленная. А если быстрая, то почему вообще сразу не сделали доп. проверку при оплате? Непонятно.

В общем, непонятно примерно везде.

[deliveryman]

Знаете, я очень детально ознакомился с вашим комментарием, и если Вы думаете, что "стрелял" и "X" имеют только одно значение, то ваша правда)

[deliveryman]

Ну и в целом - довольно просто, кажется, иметь индикатор на бэкенде, насколько быстро меняется цена доставки, и выполнять дополнительную проверку на этапе оплаты, только если если этот индикатор включён. Это если дополнительная проверка медленная. А если быстрая, то почему вообще сразу не сделали доп. проверку при оплате? Непонятно.

Судя по комментарию у вас либо не особо большой опыт в екоме, либо вы не сталкивались с подобными проблемами и решили выдать быструю экспертную оценку.

Давайте подробно разберем все ваши простые предложения:

Ну и в целом - довольно просто, кажется, иметь индикатор на бэкенде, насколько быстро меняется цена доставки

Ключевой вопрос - иметь индикатор, чтобы что? Чтобы понять когда мне нужно обновлять страницу? Зачем мне иметь этот "индикатор" на беке, когда я могу его аналитически рассчитать и далее раз в какое-то время обновлять? Зачем мне делать постоянно это в фоне, когда могу сделать один раз и в конце? А когда у вас индикатор сработал, вам нужно массово для сотни тысяч пользователей сделать одно и то же действие, вы думали о нагрузке на методы? Вы думали о безотказной работе ключевой страницы сайта?

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

А если быстрая, то почему вообще сразу не сделали доп. проверку при оплате? Непонятно.

А потому что мы не думали, что цена на услугу доставки может быть в 2 раза больше спустя какие-то 30-40 минут, и решение при котором вы нагружаете проверкой одну из важнейших кнопок сайта - не является безопасным и правильным. Подумайте над пользовательским экраном при ошибке, и что будет с бизнесом, если что-то ляжет)

ПОЧЕМУ НЕ СДЕЛАЛИ РАНЬШЕ?

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

[dyadyaSerezha]

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