Redox processes async (i.e., one-way) traffic using a first-in, first-out (FIFO) method. Learn more about async traffic. While this ensures order, it can create a bottleneck during high-volume events, like backfilling. Learn about backfilling before go-live.
To alleviate potential “traffic jams,” Redox offers a beta feature called child queues for subscriptions.
Redox can split one subscription into child queues so that event notifications can process in parallel while maintaining FIFO within each queue. In other words, one subscription can map to several queues so that async traffic processes simultaneously. The main benefit of multiple queues is faster throughput for high-volume feeds. Just make sure that the destination can handle that volume of incoming traffic.
Child queues are available for:
- async production or staging subscriptions
- subscriptions with any communication method, whether API or non-API
- traffic flowing from Redox to a destination (not traffic flowing from a source to Redox)
Queues must be set up by a Redoxer. If you’re interested in implementing this feature, talk to a Redoxer.
If you’re setting up an admission, discharge, and transfer (ADT) feed, there’s a possible conflict scenario with the Redox PatientAdmin.PatientMerge event type.
Typically, Redox splits a feed by patient identifiers. However, if one of the queues processes more slowly, you could receive a PatientMerge event for a patient that hasn’t finished processing through one of the queues.
For example, let’s say Patient 1’s record processes quickly on Queue A, but Patient 2’s record is delayed on Queue B. A PatientMerge event to merge Patient 1 and Patient 2 could then arrive on Queue A and be processed before Patient 2’s record has even arrived. This would throw an error since Patient 2 doesn’t exist in your system yet.
If this kind of conflict happens, you can retry the log message for the PatientMerge event. Learn how to retry a log.