Deleting a user from every system? The cache goes last.

transcript

You're erasing a user from a dozen systems. Order matters. And the cache, the easiest one, goes dead last.

The order: the search index, then file storage, then analytics. Then third parties like Stripe, Zendesk and Intercom. In parallel. Then the primary database. And the caches, last.

Analytics goes before the database for a reason. It needs the user ID mapping. And the primary database holds it.

Now the cache. Say you delete it before the database. A read comes in at that moment. Cache miss. It falls through to the database. Those rows aren't deleted yet. So the cache fills right back up. With the user you're deleting.

Delete the database rows first. Now no read can refill the cache. Then clear the cache. Gone for good.

And if Stripe times out mid-deletion? The run stops before the database. The database outlives the copies that still need it. A retry resumes at Stripe.

Delete the copies first, while you can still find them. The source of truth goes late. And the cache goes last.

Full breakdown in the lecture.