The dialler uses Redis to send information back to the 3rd party application. In order to make a robust messaging system we make use of two Redis data/messaging structures this enables us to ensure critical information is sent correctly. We make use of Redis PubSub and Redis Lists for all our messaging between the dialler and the 3rd party application.
Redis PubSub is a non-robust message broadcasting channel. Although it is classified as non-robust this is only because it does not handle retries, but rather works in a fire and forget approach. Although it is classified as non-robust, it is in fact very reliable and super fast. We use Redis PubSub for non-critical information as well as critical time dependant information (information which only makes sense at a specific instance in time).
Redis Lists are always populated using a push left pop right approach. Redis lists ensure the data stays persistent until it is pulled from the list. This means that the only way a message will not be delivered is if Redis DB crashes and a the record cannot be saved. In this case we have backup files which will push the message to Redis as soon as it is available again. Thus Redis lists are used for information which needs to be synced from the dialler, such as call data records.
The dialler can send back an extensive amount of information, however, the two most critical pieces of information are: agent connection notifications, and CDRs. The dialler however also sends back campaign status updates and agent status change events. These are very useful for providing a proper user experience. As the HTTP API is asynchronous they also provide the most efficient way to confirm that a request has been completed.