Как закалялась сталь и принимались решения или продолжаем сюжет из предыдущего поста 🙂 Героям нужно было понять, целесообразно ли учитывать апдейты и удаления? Делать ли пересчеты? Откуда брать данные для принятия решения? И было у них 🪑🪑🪑 1️⃣ Начислять, корректировать и удалять начисления, то есть прописать логику для всех типов событий. Это вариант очень точный, но очень дорогой, поэтому, собственно, и не подошел. 2️⃣ Обрабатывать только заказы в финальном статусе, жертвуя при этом клиентским опытом. Какой именно будет временной лаг при обработке ❔ 3️⃣Обрабатывать заказы сразу после поступления, без учета статуса. Есть риск, что какие-то удаления и апдейты исказят картину. Сколько их? Насколько они вероятны ❔ Для начала сходили к аналитикам системы-поставщика данных. Ребята обнадежили: апдейтов по ключевым параметрам и удалений ПОЧТИ НИКОГДА НЕ БЫВАЕТ. Ну кроме исключительных случаев. Ну типа если война какая-нибудь начнется (лол, извините, но так и сказали). Ответ супер, но ребята отвечали неохотно и доверия не вызывали 🤔 В серьезном деле мы могли доверять только своим красным иссушенным глазам, смотрящим в базу данных и логи. Посему решили двигаться поэтапно. Подготовительный этап: добавляем заявкам статус, один из которых будет “deleted” и устанавливаем логирование уровня Warning на изменение важных для нас атрибутов. Если они реально не будут меняться, то и следов в логах об этом не будет. Уточняющий этап: Капаем в глаза увлажняющие капли и таращимся в логи и базу данных, пока не найдем ответы на все наши вопросы. Собираем всю нужную статистику, получаем ответы от бизнеса. Гранд финале: Реализуем, наконец, фичу. Оптимальным для неё образом. Вот такой вот happy end. 🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃🙃 Интересен ли такой формат? 🦆 - нет, я захожу в тг чтобы почиллить ❤️ - да, пиши ещё 👅 - особо не читал, просто поставил эту реакцию