Subscriptions

Debezium makes it possible for mobile apps to subscribe to entities stored within a database's collections. When changes to those entities are made, Debezium captures these as events and sends push notifications to the subscribed apps so they can read and respond to the events. This page describes how this works.

Mobile push notifications

Apple, Google, and the other companies that make mobile device operating systems provide services and infrastructure for sending push notifications to devices as soon as the devices are reachable. To minimize power consumption, push notifications are lightweight messages with very small optional app-specific payloads. When a device receives its notification(s), it forwards them to the appropriate app, which can then decide how it wants to handle the notification: it can display the notification's information on the screen, it can perform work in the background, and/or it can construct a different message to display to the user.

Push notifications are usually created by backend services (like Debezium), and sent to the notification service provider via a custom API. Typically the backend service will support multiple notification service providers by using an abstraction like AeroGear Unified Push Server.

Mobile devices are not always reachable, so these notification service providers do not guarantee they will deliver all notifications. Rather, they simply attempt to deliver the most recently sent notification for each app, and may completely drop notifications if they cannot be delivered for a specified period of time. For example, if a backend service sends a notification to a device, but that device is not reachable, the notification service will enqueue that notification and deliver it when the device becomes reachable. If the backend service sends a second notification before the first notification can be delivered to the device, the notification service will discard the first (still undelivered) notification and enqueue the second notification.

Debezium subscriptions

One feature of Debezium is to allow mobile apps to subscribe to the creation, update, and/or deletion of all entities within a particular zone of a collection. Subscriptions are per device, so when an entity in a particular zone is created, updated, or deleted, Debezium will figure out which apps on which devices are interested in these events. It will then send push notifications to the apps on these devices, which can then query Debezium for all unread events.

This approach has a couple of advantages:

1. Push notifications are lightweight and delivery is not guaranteed. Debezium uses push notifications as a signal that the app on the device has unread events, so the only information within a notification is the number of unread events and an identifier of the newest event. Therefore, these notification messages are very lightweight, and it is also not a problem if some of the notification messages are discarded or dropped.
2. The app can choose to also poll for unread events. When an app is running and receives a notification of unread events, it might fetch them immediately. But if the app is not running, it is possible to simply record that there are unread events and to fetch them the next time the app is run. The bottom line is that the app has control over how and when it reacts to push notifications from Debezium.
3. Debezium can dictate the format and structure of the events, and is not restricted by the push notification service providers.
4. Timely delivery of push notifications is not required. Debezium might send a push notification to an app on a device signaling that it has 3 unread events. But before the push notification is delivered to the device, Debezium might have accumulated two additional events. When the app on the device receives the push notification saying that there are 3 unread events, it asks Debezium for all unread events and will get all 5 in the proper order.
5. Receipt of events can be guaranteed. It is possible for an app to request all unread events, for Debezium to send all unread events, but for the app to never receive the response with the events. Therefore, Debezium requires that the app also acknowledge when it has received specific events, and only when Debezium receives this acknowledgement will it mark the events as having been read.

One user, multiple devices

Debezium's subscription mechanism works when a single user has the same app installed on one device or on several devices. Each subscription is device-specific, so a user might configure the app on one device to receive events for changes to all of the user's entities, and to configure the app on a different device to receive events only for some entities.