Information Mediator - Pub/Sub use cases

This document describes the key use cases for publish and subscribe (pub/sub) data exchange. The purpose of this description is to discover technical requirements for the Information Mediator building block when defining pub/sub interactions and APIs.

Modes of pub/sub data exchange

Publishing and subscribing to messages happens in the scope of a single topic - a logical channel of messages. In most circumstances, topics are countable. For example, there’s a topic per category of message (e.g., “income tax declaration forms”), rather than per subject (“tax declaration forms from Alice”). Within the scope of a topic, parties in data exchange take the roles of a sender (publisher) and a receiver (subscriber). Below, there are a few variations of pub/sub exchange, based on the cardinality of logical senders and receivers. For example, “one” refers to a single entity (agency, business, digital service) receiving or sending, even when the workload can be technically split over multiple servers.

One-to-one

In this variation, there is exactly one sender and exactly one receiver of information. Pub/sub is to provide an asynchronous communication channel, such that a sender does not have to rely on the receiver being able to process a message. The receiver can consume and process messages at their pace. The sender might expect a response for the message. This can be an anti-pattern where pub/sub is used only for its asynchronous delivery mechanism.

One-to-many, one-to-some

A sender publishes a message that can be read by multiple receivers, at any time (or within a time window). Messages have a total or a partial order. Total order means that given any two messages you can tell which came first, a partial order means that the same applies only for a subset of messages (e.g., messages that relate to a particular context - a person, a system, a server, etc.). Receivers could be required to acknowledge that they have received a message, or to keep their own tally of messages they’ve received. The set of receivers could be known in advance (one-to-some delivery) or any authorized receiver can start consuming the messages at any time (one-to-many delivery). Messages can have a limited lifetime - new subscribers can receive only a subset of historical messages or only messages received after the point of subscription.

One-to-any

A sender publishes a message with the intent that the first receiver capable of processing the message, will consume and handle it. Receiver must acknowledge the message and could be required to send a confirmation of successful processing. The set of receivers is typically well known in advance and could have a priority order (e.g., messages are offered in round-robin fashion to add fairness).

Many-to-one, some-to-one

Multiple senders publish messages that are consumed by a single receiver. Senders get a confirmation when a message has been successfully received, and could require confirmation when the messages have been processed.

Many-to-many, many-to-any

Any number of senders send messages to any number of receivers. Senders get a confirmation when the message has been successfully received, but require no confirmation of messages being processed.

Use case examples

Notifications of closure of business entities

Description: The register of companies notifies interested parties of the closure of a company.
Benefit: Reduced business and fraud risk.
Sender: The (central) register of companies.
Receiver: Any business subscribed to the information.
Mode: One-to-many; informative only - no response expected; eventually consistent delivery (hours to days); infinite lifetime of events.
Examples: e-Business Register (Estonia) - not a pub/sub service, but conceptually could be employed as such.

Doctor’s appointment reminders

Description: A healthcare provider sends a notification to a citizen about an upcoming appointment through a central messaging platform.
Benefit: Reduced number of missed appointments.
Sender: Any healthcare provider
Receiver: Citizen who has opted in to receive notifications through their mobile device / phone / email
Mode: Many-to-one; informative events, optional response from the citizen; best effort delivery; fixed lifetime of events (expire before appointment).
Examples: GOV.UK Notify (for National Health Service healthcare providers). Suomi.fi Messages (as a platform - not used by healthcare at the moment)

Birth notification

Description: A local government finds out about the birth of a child and issues a birth certificate. Services that can be implicitly provided to the child or their family receive a notification about the birth.
Benefit: Reduced effort for parents to explicitly apply for basic child support, childcare programs etc.
Sender: Local government agency
Receiver: Any at-birth digital service provider
Mode: Many-to-many (some-to-many); eventually consistent delivery (hours to days); infinite lifetime of events; event order relevant in the context of all person-related events.
Examples: Proactive government services concept (Estonia). Life Events services (Ireland)

Task crowdsourcing

Description: A government engages citizens and collects insights through tasks that are crowdsourced to citizens
Benefit: Faster gathering of insights, feedback, and responses.
Sender: Government agency
Receiver: Any citizen registered to receive tasks
Mode: One-to-any, One-to-many; strongly consistent delivery (seconds to minutes); consumable events
Examples: CrowdTaskSG, SG Translate Together (Singapore)

Document issuance notification

Description: A government agency that is responsible for issuing a document, notifies a fixed set of subscribers of a new document having been issued.
Benefit: Reduced delay in validating a recently issued document.
Sender: Government agency issuing a document
Receiver: Agency who is required to validate a document.
Mode: One-to-some; strongly consistent delivery (seconds to minutes); infinite lifetime of events
Examples: ?

Government service interruption notification

Description: A government agency notifies that a government service (either their own or someone else’s) is experiencing an interruption.
Benefit: Faster communication of known issues and recovery progress.
Sender: Agencies registered as incident handlers or service owners.
Receiver: Any entity interested in all or a subset of availability notifications.
Mode: Some-to-many; eventually consistent delivery (seconds to minutes); limited lifetime of events (incremental updates); events have a meaningful order
Examples: Reporting the Interruption of Digital Government Services (KSA)