История про soft delete

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

История про soft delete | Сетка — социальная сеть от hh.ru