design account delete event #608

Closed
dannycoates opened this Issue Mar 4, 2014 · 6 comments

Comments

Projects
None yet
5 participants
Member

dannycoates commented Mar 4, 2014

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.

Owner

rfk commented Mar 4, 2014

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.

Owner

rfk commented Mar 4, 2014

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

Member

dannycoates commented Mar 4, 2014

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

Owner

rfk commented Mar 5, 2014

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.

Contributor

chilts commented Mar 5, 2014

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.

Owner

rfk commented Mar 5, 2014

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 added this to the Mar 14 milestone Mar 11, 2014

@rfk rfk modified the milestone: Mar 14 Mar 11, 2014

rfk was assigned by pdehaan Mar 11, 2014

pdehaan added the label Mar 11, 2014

@ckarlof ckarlof modified the milestone: Mar 28, Mar 14 Mar 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment