История про soft delete
Помню, работал над мобильным приложением для доставки товаров. В системе были корзины и заказы, связанные между собой — заказ создавался вместе с корзиной и был ключевой сущностью. Был механизм, который удалял корзины старше 30 дней. Всё работало стабильно. Потом решили написать еще один функционал, который делает примерно то же самое — и заодно удаляет связанные заказы. Решение казалось логичным, всё протестировали, выкатили в прод. Спустя время начали приходить жалобы: пользователи не могут оформить новый заказ, приложение падает. В логах стало ясно: мобильное приложение отправляет запрос с order_id, которого больше нет — заказ был удалён новым функционалом. Как выяснилось, когда-то давно мобила получила этот заказ с бэкенда и сохранила его в локальное хранилище, продолжая использовать даже после удаления. Жалоб становилось всё больше, бизнес терял деньги. Собрали аварийный созвон, на котором рассматривали разные варианты — откат через дамп не подошёл: он устарел и не содержал нужных данных. В итоге стали на лету воссоздавать удалённые заказы по запросу от клиента. В коде появилась странная логика, обильно обмазанная оправдательными комментами. Если разобраться, проблем было много: преждевременное создание заказа, локальное сохранение на клиенте, зависимость нового заказа от уже удалённого, невозможность восстановить данные из бэкапа, отсутствие ошибок на тесте и прочее. Но самая большая ошибка — физическое удаление заказов из БД. Если бы использовали мягкое удаление через флаг — можно было бы избежать всей этой истории. Теперь почти всегда удаляю мягко. И всем советую так делать.