Understanding when to use PubSub
- Last UpdatedApr 24, 2025
- 2 minute read
PubSub is well-suited for distributed scenarios where publishers and subscribers run in different silos (for example, RealTime, Historical), on different computers, or different AVEVA Enterprise SCADA systems.
The following is a list of example scenarios:
-
Accessing data from the RealTime database (RTDB) to view on a dashboard or display.
-
Publishing statistics for monitoring application or system performance.
-
Using information produced by subsystems, such as Arbitration, Health, and Process Monitoring to trigger automated responses; for example, failing over services or generating system health alarms.
The following table details design considerations to evaluate before choosing PubSub:
|
Consideration |
Recommendation |
|
What is the acceptable data latency? |
PubSub works well for low-latency transmission of data updates or changes of state where applications need the new value as soon as possible. If timely updates are not critical, should the data be polled on a periodic basis instead of using PubSub? |
|
Is there a more efficient way to get the same data? |
For example, a RealTime application can use the high-performance RealTime Application Programming Interfaces (APIs) to read directly from the RealTime database (RTDB), which is far more efficient than using PubSub. For applications that subscribe to data residing on a different silo or computer, there may be other efficient options to access the data. For example, using SQL or calling a Business Logic Tier (BLT). |
|
What is the expected rate of publications? What volume of data can be expected when an integrity update is requested? |
If data is published too frequently, the system may be overwhelmed by the number of messages. Publishers should apply deadbands to regulate the steady-state publication rate. Similarly, a large influx of integrity updates may flood the network, causing messages to be lost. Subscribers are expected to keep pace with the rate of incoming publications, whether they are integrity updates or not. Subscribers that do not keep up will be disconnected. An alternative approach is to retrieve the initial values using a polling-style method, and then subscribe without requesting an integrity update. |
|
How large is the data portion of a topic? |
PubSub messages are not optimized for large payloads, such as the contents of entire database records or files. The average payload should be in the range of tens to hundreds of bytes for best performance. |
|
Is the subscriber short-lived or long-lived? If short-lived, how often will it run? |
PubSub is designed to work best with long-lived subscribers and publishers. Short-lived and frequently started publishers or subscribers could exhaust system resources, such as the number of Transmission Control Protocol (TCP)/Internet Protocol (IP) sockets available for new connections. |