Notehub route failover logic?

A route to AWS could fail for technical or administrative issues (stuff happens…). The reroute provides automatic retries to the same route, for a few minutes. Typically not long enough to sort out the problem. Reroute also provides the option of using one ore more alternate routes. For instance Azure. How is logic at Notehub working? Parallel or serial? Does it quit on the first success?

Notehub tries to route all events “in order”. That means that as long as the routes are working, the events will be routed in the order that they are sent by the Notecard. I suspect that’s what you mean by serial.

However, if event routing fails due to a reroutable cause (e.g., Notehub is unable to connect to the route’s endpoint; a 500 error is received; etc.) and automatic retries is selected, it will be put on a queue to be retried. Those retries are essentially retried in parallel. Events will be retried up to three times over a period of 6 minutes.

If you explicitly choose to reroute events using the UI, it will send the event via all the routes you select. They will essentially be tried in parallel. It does not quit on first select.

@jcsalem Use case is minimizing note loss.
To confirm my understanding of your explanation:

Route is AWS. It has, for example, Azure + MQTT as “failover” (reroutes).
1- AWS fails (Notehub timeout on retries)
2- Notehub sends note to both Azure and MQTT
→ the note is duplicated
It is not a problem. Just confirming the need on my end to handle duplicate data.

I think I misunderstood your original question.

There is no such thing as a failover route. All routes are tried essentially in parallel. If you have 3 routes configured, we will try to route each event via all three routes.