Reapply profile suppression before a restored backup becomes readable
A restore rehearsal brings back a profile that was removed after the backup was taken.
- Focused work estimate
- 5h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Backup recovery · Deletion semantics
Estimated field mix
- Privacy engineering40%
- Site reliability30%
- Storage systems30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional collaboration product lets a member request removal of their personal profile. Search, notifications and cached displays retain copies after the primary row disappears. The exercise uses a documented product deletion policy and synthetic identities.
Setup prerequisites
- Create local profile, search-index and notification fixtures with controlled provider failures.
- Define synthetic members, organizations and a current-session authorization fixture.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- RDELETE-101 · Separate profile removal from leaving one organization
- RDELETE-102 · Verify the current member before accepting profile removal
- RDELETE-103 · Make repeated removal requests return the same active operation
- RDELETE-104 · Stop new profile-derived writes after removal begins
- RDELETE-105 · Remove profile documents from search using the removal generation
- RDELETE-106 · Track notification and cache cleanup separately from the primary profile row
Acceptance criteria
- Define a minimal removal ledger and a restore gate that reconciles post-backup removals before serving reads.
- State the retention and access boundaries of the ledger without storing full profile snapshots.
- Keep the restored environment unavailable if reconciliation is incomplete or the ledger cannot be trusted.
Implementation constraints
- Use local database snapshots and synthetic subjects; a backup exception must be visible in the policy rather than called immediate erasure.
Verification to include
- Restore a snapshot containing a later-removed profile and verify suppression before any simulated read endpoint is enabled.
- Make the ledger unavailable and verify the restore gate fails closed.
Deliverables
- Restore reconciliation protocol and backup resurrection rehearsal
Rollout and recovery
Add the gate to the local restore runbook before accepting the deletion workflow as complete for its declared stores.
Value of the work
For the engineer: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states.
For the team: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.