PubSub. The second round.

Motivation.

The current implementation of the PubSub module is based on the RFC discussed and approved. But there was a decision that the current implementation would be an MVP and would contain vital functionality only. Nowadays as the PubSub module is being started to be used for complex workflows, its limited functionality becomes a blocker for some cases and sometimes requires finding and/or creating workarounds.

This document is intended to gather and discuss functional and non-functional requirements that define the functionality that must be implemented in the next Pub-Sub development iteration.

Requirements.

Functional requirements

1. Based on underlying messaging engine capabilities, PubSub must provide exactly once delivery guarantees each message is delivered once and only once.
2. It should be possible to notify a publisher that there are no subscribers for an event type it is trying to send. It could be included in a response to an event publishing call.
3. Time to live (TTL) must be set up for each event sent. It optionally allows a publisher to provide a callback endpoint or an error “Event Type” to be notified that despite the fact that there are subscribers for such an event type no one has received the event within the specified period of time. If a TTL is not explicitly specified for an event, the default TTL for the event type will be used.
4. Subscriber once received an event can’t rewind and receive the event one more time

Non-functional requirement

1. It is expected that some payload can be up to 1Mb in size. PubSub must allow to process quite a long sequence of such events (up to 7,000,000 events)
2. It is expected that TTL for any event will not be longer than several minutes (3-5).