> For the complete documentation index, see [llms.txt](https://islamu.gitbook.io/islamu-event/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://islamu.gitbook.io/islamu-event/documentation/readme/security-and-identity/privacy-erasure.md).

# Privacy Erasure

Understand the GDPR Right-to-Erasure workflow, anti-resurrection fences, and authority storage topologies.

Under data privacy regulations such as the GDPR, when an attendee or user requests account deletion, the platform must guarantee that their personal identifiable information (PII) is completely destroyed and **cannot be accidentally resurrected** by database restore operations or distributed retries.

ISLAMU Event implements an **Authority-First, Anti-Resurrection Architecture** to enforce this guarantee.

***

## The Anti-Resurrection Workflow

The erasure process follows a strict sequence to prevent data leaks or partial deletions:

```mermaid
sequenceDiagram
    autonumber
    actor User as User / Data Subject
    participant API as Explore.API
    participant Fence as Memory/Redis Fence
    participant AuthStore as Privacy Erasure Authority
    participant AppDB as Primary Application DB
    participant Outbox as Provider Cleanup Outbox

    User->>API: DELETE /api/user (Idempotency-Key: UUIDv7)
    API->>Fence: Establish Anti-Resurrection Fence (blocks new logins/writes)
    API->>AuthStore: Record Typed Immutable Erasure Fact (Monotonic Counter)
    API->>AppDB: Serializable Settlement (Purge PII, anonymize foreign keys)
    API->>Outbox: Enqueue async cleanup (Keycloak user, avatars in S3, Stripe customer)
    API-->>User: 202 Accepted (Location: /api/privacy-erasure/status + ErasureReceipt)
```

1. **Anti-Resurrection Fence**: An immediate barrier is established in distributed cache. Any concurrent or subsequent requests with this user ID are blocked instantly.
2. **Authority Fact**: The erasure event is recorded in a dedicated, isolated authority store *before* local data disposal begins.
3. **Serializable Settlement**: In one atomic transaction, the user’s personal data is scrubbed, registrations are anonymized, and foreign keys are safely unlinked.
4. **Asynchronous External Cleanup**: Background outbox workers delete the user from Keycloak, purge media from S3/local storage, and notify external payment gateways.
5. **Single-Use Receipt**: The user receives a `202 Accepted` response with an opaque `ErasureReceipt` capability token. The receipt can be used to query `/api/privacy-erasure/status` until completion, after which all trace of the receipt is destroyed.

***

## Choosing an Authority Storage Topology

The Privacy Erasure Authority store must be configured in your environment via `PRIVACY_ERASURE__AUTHORITY__TOPOLOGY`:

| Topology               | Storage Mechanism                                                     | Best Fit                              | Primary Constraint                                                    |
| ---------------------- | --------------------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------- |
| **`EmbeddedSqlite`**   | Dedicated SQLite database at `/app/data/privacy_erasure_authority.db` | Single-server Compose and Standalone  | Single API container writer; requires volume persistence              |
| **`CoLocated`**        | Shared table schema within primary PostgreSQL DB                      | Minimal dev environments              | No independent protection if primary DB is restored from stale backup |
| **`ExternalDatabase`** | Completely isolated external PostgreSQL instance                      | High-availability enterprise clusters | Requires managing a secondary PostgreSQL database                     |

> \[!TIP] **Our Recommendation:**
>
> * **We recommend `EmbeddedSqlite`** for standard self-hosters. It runs with zero operational overhead, uses dedicated storage, and guarantees that even if your primary PostgreSQL database is restored to a state from last week, the SQLite erasure store will prevent previously deleted users from being resurrected!
> * **We recommend `ExternalDatabase`** only for enterprise multi-node clusters running multiple API replicas that cannot share a local SQLite file.

***

## The Golden Rule of Disaster Recovery

> \[!CAUTION] **Never Restore the Primary Database Without the Erasure Store!**\
> If you restore an older database snapshot (e.g., from 3 days ago) to recover from corruption, any user who requested account deletion yesterday would normally be restored ("resurrected") into the database.
>
> When ISLAMU Event starts, the **`PrivacyErasureStartupGate`** automatically replays all facts from the Privacy Erasure Authority against the application database before HTTP traffic is allowed. If an erased user is found in the restored database, the gate immediately re-purges their records and re-establishes the anti-resurrection fence!

***

## Related Guides & Next Steps

* [**Backup, Restore & Upgrade**](/islamu-event/documentation/readme/configuration-and-operations/backup-restore-upgrade.md) — Production backup scripts and disaster recovery rehearsals.
* [**Docker Standalone Runbook**](/islamu-event/documentation/readme/self-hosting/docker-standalone.md) — Operate the embedded SQLite erasure authority on a single server.
* [**Environment Variables Reference**](/islamu-event/documentation/readme/configuration-and-operations/environment-variables.md#7-privacy-erasure-authority-gdpr--anti-resurrection) — Configure erasure topology and busy timeout dials.
* [**Custom Properties Governance**](/islamu-event/documentation/readme/events-and-ticketing/custom-properties.md) — Learn how long-tail attendee answers are scrubbed during account deletion.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://islamu.gitbook.io/islamu-event/documentation/readme/security-and-identity/privacy-erasure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.