California Just Made Broken Deletion Costly

As of August 1, California's data deletion requests — known as DROP requests — carry real enforcement weight. Not "we'll look into it" weight. Fines, audits, and statutory damages weight. If your app serves California users, that means you.

Here's the problem: most "delete my account" endpoints are theatrical. They drop a row from the users table and call it done. Meanwhile, the user's data lives on in seven other places you forgot about.

Why this matters

CPRA gave California residents the right to request deletion of their personal data. The enforcement mechanism just kicked in. Companies now face penalties for failing to honor these requests within 45 days.

This isn't a legal team problem. It's an engineering problem. Legal can't delete data from your Redis cache, your Elasticsearch cluster, your analytics warehouse, or the CRM your marketing team quietly connected last quarter.

How it works

A real deletion pipeline needs to touch every store that holds user data. That means mapping full data lineage: where personal data enters, where it gets replicated, where it gets transformed and stored again.

The hard part isn't the primary database. It's the fan-out. User data typically lives in:

• Primary database (easy — DELETE WHERE user_id = ?)
• Caches and session stores (often keyed differently or denormalized)
• Search indexes (separate delete API or reindex)
• Analytics warehouses (append-only by design — deletion is anathema)
• Third-party services (Stripe, Salesforce, Mixpanel — each has its own API and timeline)
• Backups (deleted data shouldn't resurrect after a restore)

Each sink requires a different deletion mechanism. Some don't support targeted deletion at all.

Where this helps

Building the pipeline now means you're not scrambling during an audit. The pattern that works: a deletion job queue that fans out to every data store with idempotent handlers for each sink.

Vendor forwarding — you're responsible for deletion even when a third party holds the data. You need to propagate requests and verify completion, not just fire and forget.

Audit trails — keep a tamper-evident log of what was deleted, when, and from where. Regulators will ask for proof.

Watch out

Analytics warehouses are the worst case. Snowflake, BigQuery, and Redshift are built for append-only workloads. Deleting individual user records from partitioned fact tables is expensive and sometimes impossible without full reprocessing.

Backups create a legal gray area. Most guidance says you don't need to scrub backups — but deleted data must not reappear in production after a restore. Keep deletion tombstones that survive restores.

Soft deletes count as retention, not deletion. If you're setting deleted_at and keeping the row, you haven't deleted anything.

Try it yourself

Map your data flow first. Here's a quick audit query to find every table holding user references:

-- PostgreSQL: find every column likely tied to a user
SELECT table_name, column_name
FROM information_schema.columns
WHERE column_name IN ('user_id', 'userid', 'customer_id',
                      'email', 'owner_id', 'account_id')
ORDER BY table_name;

If the result set is longer than you expected, you have work to do before the first request lands.

TL;DR

• What changed: California DROP deletion requests became enforceable August 1, with real penalties for non-compliance.
• Why it matters: Most deletion endpoints are incomplete — data survives in caches, analytics, and third-party tools.
• What to try today: Audit every data store for user references, then start building a deletion fan-out pipeline before enforcement comes knocking.