Decide on Queue Mechanism

[stephenmichaelf]

Azure Service Bus?

Some discussion has happened in Gitter on requirements for this:

• I like the idea of queues alot, but they can bring some design decisions that need making upfront for performance issues (Because lets face it Github produces alot of Notifications lol). How long do we keep the messages? Do we requeue and circle them? If they are stale (i.e. haven't been read for X long) do we Store them if no processed. How do we register interest in a message so that if NotificationDbWriter picks it up, we make sure the message is still available to be processed by other Services?
• I would suggest to use repo-policy for retirement. Default 6 months / 1 year.
• I like that idea but I would wait for other messages that are close to reach that X mins/hours so that we don't fill that service with requests. Imagine thousends of queued notifications by 1 min time gap are queued and then each of them starts passing that time limit one bye one and we start sending requests per message. I would send them by chunks -- maybe not all of them as then the first one that was supposed to get out of the queue would be there for a thousand minutes waiting for the next. Maybe a time range more than a time gap would be nice to expire them.

[karelz]

@stephenmichaelf not sure why you assigned the design decisions to me ... I would rather have a discussion on the topic and then we can decide together.
I don't have specific expertise in the space, beyond general componentisation design approach ;)