Пользовательские данные нужно удалять мягко
Симптом
Пользователь случайно удалил нужные чаты и попросил восстановить их.
Контекст
Чаты удалось вернуть, обнулив delete_at в записи базы данных. Восстановление
сработало, потому что удаление было логическим: исходные данные ещё находились в
хранилище, а запись сохраняла признак удаления.
Корневая причина
Операция удаления меняла состояние записи, но не уничтожала её физически. Это создало возможность восстановления без реконструкции содержимого из резервной копии.
Ошибочное предположение
Удаление часто воспринимается как одно необратимое действие. Для пользовательских данных это не всегда лучший default: случайное нажатие или ошибка интерфейса не должны сразу превращаться в потерю всего содержимого.
Обнаружение
Инцидент обнаружился по обращению пользователя. Раньше проблему помогли бы обнаружить метрики восстановлений и периодическая проверка того, что soft-deleted записи скрыты из обычных запросов, но доступны контролируемому recovery-пути.
Исправление
Для чатов и других восстанавливаемых пользовательских объектов использовали
soft-delete с полем delete_at. Обычные запросы исключали удалённые записи, а
восстановление стало отдельной авторизованной операцией с журналом.
Физическое удаление выполнялось позже по retention policy, когда окно восстановления завершилось.
Такая схема не должна противоречить пользовательскому соглашению: сроки хранения, возможность восстановления и окончательного удаления должны совпадать с явно описанными пользователю правилами.
Проверка
Регрессионный сценарий должен проверить, что удалённый чат:
- исчезает из обычной выдачи;
- остаётся доступен recovery-операции;
- восстанавливается с исходным содержимым;
- после физического удаления больше не восстанавливается.
Общий вывод
Пользовательское удаление должно разделять скрытие данных, восстановление и окончательное уничтожение. Soft-delete сохраняет возможность исправить ошибочное действие, но требует строгих прав доступа, retention policy и очистки обычных запросов от удалённых записей.