Запрос на удаление нельзя выполнить одним DELETE в таблице пользователей. В приложении с несколькими модулями информация может находиться в связанных записях, файлах, поисковых индексах, очередях, экспортах или внешних сервисах. Удаление только видимой учётной записи может оставить доступные копии; бездумное удаление, напротив, может затронуть данные, которые необходимо сохранить для работы других процессов.
Проверяемое удаление данных в PHP следует проектировать как процесс с явно заданным охватом, ответственными, состояниями, повторными попытками и проверками. Операционная цель — не обещать, что любые копии исчезнут немедленно, а иметь возможность определить, какие системы обработаны, какой результат получен в каждой из них и какие ограничения ещё остаются.
Определите охват до начала выполнения
Преобразуйте запрос в перечень категорий данных и систем. Например, у учётной записи могут быть профиль, настройки, сессии, документы, комментарии и события активности. Ссылки на неё также могут встречаться в счетах или других общих записях. Для каждой категории решите, следует ли удалить данные, отвязать их, анонимизировать или сохранить в соответствии с применимой внутренней политикой. Не считайте эти варианты равнозначными: при анонимизации человек не должен оставаться идентифицируемым в предусмотренном контексте, а отвязка не обязательно удаляет исходные данные.
Также определите, что означает «завершено» для каждой системы. Удаление строки из основной базы данных не доказывает, что обновлён поисковый индекс или удалён файл. Разделите системы, находящиеся под непосредственным контролем — базу данных, объектное хранилище, кеш, — и системы, зависящие от поставщика или срока хранения, например некоторые резервные копии. Итоговый статус должен отражать эти различия, а не скрывать их за единой меткой успешного выполнения.
Составьте перечень копий и назначьте ответственных
Перечень должен отражать реальные потоки данных, а не только схему базы данных. Проверьте, где данные создаются, экспортируются или преобразуются: очереди задач, поисковые индексы, аналитические системы, временные файлы, журналы приложения и подключённые инструменты. Уточните у каждой команды, по какому идентификатору можно найти записи и какую операцию поддерживает её система.
Назначьте технического ответственного за каждую систему и задокументируйте механизм, ожидаемый ответ, повторные попытки и ограничения. Если система не позволяет выполнять поиск по стабильному идентификатору, этот недостаток затрудняет проверку и его следует считать техническим долгом проектирования. Не храните дополнительную копию персональных данных непосредственно в записи запроса: обычно достаточно внутреннего идентификатора обращения, необходимых для выполнения операции ссылочных данных и минимизированных результатов.
Моделируйте состояния и результаты по каждой системе
Надёжный процесс имеет явные состояния, например: received, validated, in_progress, partially_completed, verification_pending, completed и failed. Согласуйте переходы между ними и определите, кто может их инициировать. Не следует помечать запрос как завершённый, пока по обязательным системам нет проверяемого результата.
Фиксируйте результат отдельно для каждой системы: ожидает обработки, удалено, не найдено, можно повторить попытку, требуется проверка или действует задокументированное ограничение. «Не найдено» может быть допустимым результатом, но только если поиск выполнялся по правильному ключу и охватывал нужный объём данных. Отличайте временную ошибку — например, недоступность сервиса — от окончательного отказа, требующего вмешательства.
В PHP отделяйте координацию процесса от работы с конкретными системами. Сервис приложения может загрузить обращение, проверить права доступа и отправить задачи на выполнение; отдельные адаптеры реализуют операции для базы данных, хранилища или API. Тогда изменение поставщика не потребует смешивать бизнес-логику с деталями передачи данных. Также защитите создание обращения и доступ к нему проверками прав и фиксируйте, кто инициировал административные действия.
Упорядочьте удаление с учётом зависимостей
Перед удалением определите, какие связи зависят от учётной записи, а какие используются совместно. Внешние ключи и правила каскадного удаления помогают поддерживать целостность, но каскад может удалить больше данных, чем предполагалось, если модель смешивает личные и общие данные. Оцените влияние каждой связи и предпочитайте явные операции, если охват не очевиден.
Типичная последовательность включает остановку новых записей, связанных с субъектом, отзыв сессий или учётных данных, удаление внутренних зависимостей, удаление или преобразование собственных записей, а затем распространение операции на индексы и внешние сервисы. Конкретный порядок зависит от архитектуры. Если сначала удалить ключ, по которому находятся данные в других системах, задача может потерять сведения, необходимые для продолжения. Храните эту рабочую ссылку в защищённом виде и только в течение необходимого срока, не превращая журнал операций в параллельное хранилище.
Сделайте процесс идемпотентным и возобновляемым
Распределённые задачи могут завершиться с ошибкой после выполнения операции, но до отправки подтверждения. Поэтому каждый шаг должен допускать повторный запуск без нежелательных последствий. Идемпотентное удаление может считать отсутствие записи допустимым и возвращать контролируемый результат, а не всегда трактовать его как ошибку.
Сохраняйте прогресс отдельно для каждой системы и используйте ключ идемпотентности или стабильный идентификатор обращения, если удалённая система это поддерживает. Выполняйте обработку каждой системы в подходящей транзакции или единице работы, не оставляя транзакцию базы данных открытой на время ожидания ответа API. При сбое повторяйте попытки с ограничением их числа и стратегией задержек; ошибки, для которых попытки исчерпаны, должны попадать в очередь на проверку, а не исчезать в журнале.
Возобновление должно продолжать процесс с незавершённых шагов. Не перезапускайте весь процесс, если это может повторить небезопасные действия или перезаписать предыдущие результаты. В частности, различайте «запрос отправлен» и «удаление подтверждено»: успешный HTTP-ответ может подтверждать получение запроса, но не обязательно завершение удалённой операции. Согласуйте с поставщиком значение каждого подтверждения.
Проводите проверку, не сохраняя удаляемые данные
Способ проверки должен соответствовать системе и типу операции. В базе данных запрос по предусмотренным ключам может подтвердить, что в заданном охвате больше не осталось строк. В хранилище можно проверить отсутствие объекта или ответ механизма удаления. В индексе нужно запросить документ по подходящему ключу и учесть задержку распространения изменений. Сообщение работника об успешном выполнении не заменяет эти проверки.
Фиксируйте минимально необходимое подтверждение: идентификатор обращения, систему, операцию, временную метку, статус, число затронутых элементов, если это безопасно, и техническую ссылку на результат. Не копируйте удалённое содержимое, учётные данные, токены или ненужные персональные идентификаторы в журналы и метрики. Защитите журнал аудита, ограничьте к нему доступ и определите срок хранения согласно внутренней политике. Подтверждение должно позволять объяснить ход процесса, не восстанавливая информацию, которую пытались удалить.
Учитывайте ограничения и проверяйте процесс
Для резервных копий нужно явно определить порядок действий. Выборочное удаление может быть недоступно немедленно; задокументируйте предусмотренный срок хранения и способ предотвратить повторное появление уже удалённых данных после восстановления. Например, процедура восстановления может повторно применить ожидающие или уже завершённые запросы до включения восстановленной системы. Не утверждайте, что копия удалена, если доступный механизм лишь позволяет ей истечь по окончании срока хранения.
Для внешних систем укажите, кто может инициировать операцию, какое подтверждение предоставляет поставщик и в каких случаях неопределённый результат следует эскалировать. Операционное ограничение не равнозначно успешной проверке: в зависимости от имеющихся подтверждений его следует обозначить как ожидающее, ограниченное или устранённое.
Перед запуском проверьте процесс в непроизводственных средах на синтетических данных: дублирующиеся запросы, общие связи, отсутствующие файлы, тайм-ауты, неоднозначные ответы и сбои после завершения одного из шагов. Убедитесь, что повторные попытки не дублируют эффекты, проверки прав блокируют неправомерный доступ, а отчёты не раскрывают данные. В рабочей среде отслеживайте количество сбоев, срок, в течение которого обращения остаются в ожидании, и системы без подтверждения, не добавляя персональную информацию в оповещения.
Контрольный список: определены охват и исключения; составлен перечень систем и ответственных; задокументированы состояния и переходы; проверены зависимости; шаги идемпотентны и допускают возобновление; для каждой системы предусмотрена отдельная проверка; подтверждения минимизированы и защищены; ограничения резервных копий и поставщиков доведены до сведения; проведены тесты сбоев; доступна процедура проверки и эскалации. Эти меры позволяют команде обеспечить прослеживаемость и точно определить, на каком этапе остановилось удаление, вместо того чтобы путать начатое действие с подтверждённым результатом.
