Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

design account delete event #608

Closed
dannycoates opened this Issue · 6 comments

5 participants

@dannycoates
Owner

Other services are interested in the account delete event and maybe others in the future.

https://bugzilla.mozilla.org/show_bug.cgi?id=971907

The auth server should announce this somehow that doesn't couple it to a particular backend.

My current thought is to write events to stdout and pipe to a second process that sends it where it needs to go. This will make dev easy by just writing it to /dev/null while an AWS handler can write to db and/or SQS.

@rfk
Owner
rfk commented

I like the simplicity of this approach. I worry about the consumers of this stream getting out of sync with the FxA database state and e.g. blowing away data for a user whose account-deletion request didn't actually stick, or hanging onto zombie data for an account that was deleted but whose announcement got lost in the mail.

@rfk
Owner
rfk commented

(Of course the answer might be "so stop worrying about that" and that's ok too...)

@dannycoates
Owner

hanging onto zombie data for an account that was deleted but whose announcement got lost in the mail

It seems like the only way to guarantee the event for a delete doesn't get lost is to create it in the db in the same transaction as the delete because processes can crash at any time.

blowing away data for a user whose account-deletion request didn't actually stick

The handler could verify the account record is gone before broadcasting the message it we want to be doubly sure. But then you may as well do the above and just read from that table.

Does that make it worth it? I don't know. maybe

@rfk
Owner
rfk commented

Yeah. Let's go with "don't worry about that for now" and just slurp the events up from stdout, and have another process on the box post them to an SQS queue. We can revisit the QoS of this system once it has a few more downstream users and more precisely scope requirements.

So, perhaps it will suffice to just have a helper process that finds successful "destroy account" requests in the existing output logs and sends them off to the appropriate place.

@chilts
Owner

I think you guys are thinking of SNS, not SQS. ie. multiple things can subscribe to SNS and therefore the message will be delivered to as many things as subscribe to it. Whereas SQS means only one 'thing' can pop the message off the queue (and then ack it).

For SNS you can deliver to different endpoints such as email, an SQS queue or a http/https endpoint (among others). I think this latter delivery mechanism (hitting a http/https endpoint) might be a great solution. ie. it's a webhook when something happens, e.g. a user has been deleted.

Each service interested in account deletion events can just subscribe to the SNS "fxa-account-deleted" topic. AWS will do all the heavy lifting.

@rfk
Owner
rfk commented

I was considering SQS in the first instance because we only have a single downstream consumer to start (tokenserver) and because it seems to have a bit better reliability match for our needs here (e.g. at-least-once delivery, explicit message ack). But I should take another look at SNS.

@pdehaan pdehaan added this to the Mar 14 milestone
@rfk rfk modified the milestone: Mar 14
@rfk rfk was assigned by pdehaan
@pdehaan pdehaan added the label
@ckarlof ckarlof modified the milestone: Mar 28, Mar 14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.