Stream store notification

Notifications are asynchronous to the activities that creates them. Some notifications may altogether be missed, raised incorrectly or occur more than necessary. Tests for notifications span all such operations that result in notifications, target all types of notifications and their payloads. Any policy parameters that result in a different outcome is also candidate for tests.

Notifications are events by nature. All tests applicable to events are also candidates for notification with the observation that notifications are in response to operations on the control plane. They are not data and should ideally be published and subscribed once during its lifetime. There is no purpose to notifications after they have been addressed.

That said, there can be many subscribers to the same notification. All registered subscribers should be able to get each notification. Depending on the scope, purpose and duration, subscribers may be registered on different interfaces to receive only the notification they are interested in. This alleviates the need to provide filters on notifications. Persisted events follow a different model. They are available for analysis via stream processing language.

The number of segments in a stream changes when it is auto scaled by the store. The segments can also be scaled manually with the help of scaleStream method on the controller. This method allows parallelization of read and with the use of readers assigned to a reader group should receive notifications. The poller on the client detects changes in the synchronization state but this is invoked only when the stream store updates it. The reassignment of readers to segments is an indicator for notifications on the reader group. Therefore, manual scaling must be followed by stream store reconciliation of reader group prior to notifications getting sent.