There is another option, and that would be to configure Destination1 and Destination2 as DR-mates with 2 messaging-VPNs across them. The DR mechanism is different than bridging/DMR in that it adds an extra layer to to keep the two sites synchronized in lockstep at all times, rather than as distinct sites with their own configurations. Let’s see if Markdown can capture it
+---+------++------+--+
|D1 |VPN1 ||VPN2 | |
| |(Live)||(Stby)| |
+---|------||------|--+
| | || ^ |
| | || | |
| V || | |
+---|------||------|--+
| |VPN1 ||VPN2 | |
|D2 |(Stby)||(Live)| |
+---+------++------+--+
What that means is that VPN1 and VPN2 are virtualized across the two sites, and you can designate which destination is active for each VPN. That way, you can accept connections to VPN1 on Destination1 and sync it to Destination2. And accept connections to VPN2 on Destination2 while synchronizing it to Destination1.
That way, if either side fails, you can flip its peer from Standby to Live and it will begin accepting connections from all clients, and the VPNs will be in sync with all their queues, and at the last synchronized point of consumption.
I realize this gets pretty complicated. Can have an offline conversation with you about it if you’d like.