Skip to main content
Version: 2.2.0

Operating Concepts

The following diagram depicts the operating concepts of RTUS:

  • RTUS provides a set of REST APIs for Application Services to publish updates to Clients using the following data structure:
    • Map : key-value pairs
    • User Value Map : key-value pairs where key is the user id.
    • Topic : pub/sub channel where updates are sent to client that subscribe to the channel.
  • Client can subscribe specific SSE endpoints to receive updates from RTUS.

Map​

  • Map represent a key-value store.
  • A Map is unique within a tenant. Different Map with the same name can exists in different tenants.
  • A tenant can have one or more Maps.
  • A Map can store one or more Value of application/json or text/plain content type.
  • Each Value is associated with a unique key. When a Value is added to the Map and another Value already exists within the Map with the same key, it will replace the old Value in the Map.
  • One or more Clients can subscribe to receive change notifications in same Map. The types of changes notification are:
    • Added : when new key-value pair is added to the Map
    • Updated : when new Value replaces the old Value with the same Key in the Map
    • Removed : when the key-value pair is removed from the Map
    • Map Cleared : when the Map is being cleared; all key-value pairs are removed.
    • Client can subscribe to Map with parameter init set to true which will return all key-value pairs exists in the Map at the point of subscription.

JSON Map​

  • JSON Map represent a key-value store.
  • A JSON Map is unique within a tenant. Different Map with the same name can exists in different tenants.
  • A tenant can have one or more JSON Maps.
  • A JSON Map can store one or more Value of application/json content type.
  • Each Value is associated with a unique key. When a Value is added to the Map and another Value already exists within the JSON Map with the same key, it will replace the old Value in the Map.
  • One or more Clients can subscribe to receive change notifications in same Map. The types of changes notification are:
    • Added : when new key-value pair is added to the Map
    • Updated : when new Value replaces the old Value with the same Key in the Map
    • Removed : when the key-value pair is removed from the Map
    • Map Cleared : when the Map is being cleared; all key-value pairs are removed.
    • Client can subscribe to Map with parameter init set to true which will return all key-value pairs exists in the Map at the point of subscription.

User Value Map​

  • User Value Map represent a key-value store where the key is the User Id.
  • A User Value Map is unique within a tenant. Different User Value Map with the same name can exists in different tenants.
  • A tenant can have one or more User Value Maps.
  • A User Value Map can store one or more Value of application/json or text/plain content type.
  • Each Value is associated with a unique key, which is user id. When a Value is added to the Map and another Value already exists within the Map, it will replace the old Value in the Map.
  • Client can subscribe to receive change notification on a specific Key (User Id) in a User Value Map.
  • One or more Clients can subscribe to receive change notifications on the same Key (user ID) in the same Map. The types of changes notification are:
    • Added : when new Value is added for the subscribed Key in the User Value Map
    • Updated : when new Value replaces the old Value for the subscribed Key
    • Removed : when the Value is removed from the subscribed Key
    • Map Cleared : when the Map is being cleared; all key-value pairs are removed.
  • Client can subscribe to Key in the User Value Map with parameter init set to true which will return existing Value associated to the Key at the point of subscription.

Topic​

  • Topic is a categories used to organize Events for subscription.
  • Each Topic is unique within a tenant. Different Topic with the same name can exists in different tenants.
  • A tenant can have one or more Topics.
  • A Topic can be used to publish any Event of application/json or text/plain content type.
  • Each Event is associated with an Event Id.
  • Event published to Topic will be stored in Topic and only will be removed when the following conditions happen:
    • RTUS is restarted
    • Topic is full. When Topic is full, oldest Event will be remove to make space for new Event. The default capacity for Topic is 100 and can configured.
    • Event expired. Each Event in the Topic has a default time-to-live of 300 seconds. This setting control how long Events can remain in the Topic before they are expired and removed.
  • Client can subscribe to receive Event in a Topic.
  • One or more Clients can subscribe to receive Event from the same Topic.
  • Client can optionally supply the last event id received when subscribe to a Topic. When specified, the Client will be able to receive Event starting from the next Event after the last event id. If the next Event after the last event id is no longer exists in the Topic, due to expiration or Topic capacity full, then the Client will start receive from the next oldest Event in the Topic.