Introducing Miranda: Subscriptions

In preparation for a talk I'm giving at DOSUG I'm going to post my thoughts as they develop.

Subscriptions ensure that Events sent to a Topic also get sent to the subscriber.

They consist of the user that created them, a URL where the events should be sent, a liveliness URL, and some attributes.

Users who can create subscriptions are called subscribers.  They can use the web site or the API to create a subscription.

When an event is delivered to the URL associated with a subscription and Miranda gets back a 2xx result, it is called a Delivery.

A subscription has attributes that control its behavior such as:

• What to do with failed Events.  Does the system keep trying to deliver the Event, or does it put the failed Event into a list of failed Events.
• How does the system handle recording Deliveries?  Does it move on after a Delivery has occurred, or does it wait for the delivery to be written to persistent store?
• How does the system deal with other nodes?  Does it wait for acknowledgement or for  the other nodes to write the Delivery?

The owner of a subscription or the admin can change it through the web site or the API.

A subscription can be deleted by the owner or the admin.  All messages that have not been delivered are lost.

Elections determine which node handles deliveries for the subscription.

If the system cannot deliver an Event for a subscription because it did not receive a reply from the URL it tries to contact the subscriber via the liveliness URL. If it fails to contact the liveliness URL, it keeps trying, waiting twice as long between attempts until it reaches a limit of 5 minutes (default).

It keeps trying the liveliness URL every 5 minutes until it gets a 2xx result, at which time it resumes delivery of Events.  Miranda keeps Events for one week (default) before discarding them.