redis – Resilient user deletion flow in node.js: balancing auth invalidation and distributed cleanup (Supabase, RevenueCat)

I am implementing a user account deletion flow in a node.js backend. My stack involves Supabase (auth, db and storage), RevenueCat and Redis. Initially i was thinking about enqueuing a job with bullmq with the following flow:

1. delete user storage using supabase-js

2. delete customer from RevenueCat using their api

3. delete user records using supabase-js

4. sending confirmation email

The issue with this approach is that it leaves a small gap where user could still make requests until deleteUser gets called. I thought about adding a ban call after enqueuing the job to mitigate but it might fail. I also considered hard deleting user before enqueuing the job but the risk is having “orphaned” data if the enque fails.

What are the best practices for handling account deletion when it involves multiple third-party apis that don’t support “transactions”?

How can i mitigate the auth-gap between delete request and job starting?

Is it better to leave the deletion of user records as last step or better as first?

Are there alternative patterns that fit well within the supabase/node.js ecosystem for this use case?