Stream store notification continued

The notifications are purely a client-side concept because a periodic polling agent that watches for the number of segments and the number of readers can raise this notification. The stream store does not have to persist any information. Yet the state associated with a stream can also be synchronized by persistence instead of retaining it purely as an in-memory data structure. This alleviates the need for the users to keep track of the notifications themselves although the last notification is typically the most actionable one and the historical trend only gives an indication for the frequency of adjustments.

The notifications can also be improved to come from the writer side because the writers are aware of the current and active segments being written to and when they are sealed since the previous segment will not be the same as the current for the event written after sealing. These writer-side notifications can give indication to the distribution of events written to segments across key-space. 

Notifications could also be improved to come from segments, streams and scopes for all operations associated with them. They need not just be made available on the reader group. They can be made available via a subscriber interface available globally.

There may be questions on why such information on segments, streams and scopes need to come from notifications as opposed to metrics which are suited for charts and graphs via existing time-series database and reporting stack. The answer is quite simple. The stream store is a time-series store and should promote its own stack with the beautiful stream processing language and store that it supports. All the notifications are events and those events are also as continuous as the data that generates them. They can be persisted in the stream store itself.

When the events are persisted in the stream itself, the publisher-subscriber interface then becomes similar to writer-reader that the store already supports. The stack that analyzes and reports the data can read directly from the stream. Should this stream be internal, a publisher-subscriber interface would be helpful. The ability to keep the notification stream internal enables the store to cleanup as necessary. Persistence of events also helps with offline validation and introspection for assistance with product support.

Notifications on the reader group are interesting when readers come and go. Changes in both number of segments and number of readers could renew notifications to the reader group.