RabbitMQ Queues

The RabbitMQ queues are engineered to be volatile. All queues are relevant only to the open GUI sessions, API interactions, and open database connections. In the event of a disaster recovery scenario, the information in the RabbitMQ queues are irrelevant for the recovery of the system.

If system outage causes the RabbitMQ process to fail, all messages and their data are lost. The system does not keep a copy of the messages in the database or in a local extents file. To recover, the user must resend/redo the operations that generated the lost messages.

If EnterWorks’ microservices go down and the queues are still up, messages wait to be processed by the system. Microservices will start processing the queued messages upon startup.

There are scenarios during a Rabbit MQ outage in which an error may be logged, such as “Could not hold any more messages”. The system may have persisted all messages. In order to recover the overall system, removal of all messages on local storage may be required.

EnterWorks microservices reply to anonymous queues. These queues are not persistent nor exclusive. The processes using these queues execute in the background. There is no need to back up or restore these queues. Further, all RPC calls are not executed. They are not mission-critical to the operation and have no disaster recovery requirement.