Multiple MQTT brokers and down messages

The MQTT configuration is defined per region, and each region should have an unique ID. ChirpStack stores the region ID in the device-session of each device, and thus knows which region context and MQTT broker to use when sending the downlink.

if there are two Chirpstack servers handling different sets of devices (based on region config), using the same database

All ChirpStack servers should have the same (region) configurations if they are pointing to the same database. Each ChirpStack instance should be able to handle any uplink / downlink. If not, you will run into issues. E.g. on downlink, the region ID associated with the device is unknown.

So in short, you can have multiple MQTT brokers (e.g. one for EU and one for US), but you should have one ChirpStack cluster (e.g. configured to handle EU + US regions).

Thanks for the clarification on the region configuration needing to be the same on all ChirpStack servers.

However, this implies my goal of setting up ChirpStack servers in both regions will not work as intended. I want message the path of UE gateways to be:

EU gateway --> EU MQTT broker --> EU CS server --> My App
My APP --> EU CS server --> EU MQTT broker --> EU gateway

All ChirpStack servers should have the same (region) configurations

If I violate this by pointing the EU CS server eu868 config to the EU broker and the US CS server eu868 config to the US broker (only used for testing in the US), I understand a downlink message sent to an EU device using the US CS server would fail.

To get around this, I am thinking I can add a region tag to CS applications, region=eu for example. Then, assuming my application is configured to know which CS servers are in which region, the downlink message could be sent to the proper CS server. (My App already knows the application of the device, retrieved via CS API) Will a configuration such as I am describing introduce any other negative side effects? All CS servers are using the same PostgreSQL and Redis (Valkey) instances.

I realize this is not the intended architecture, but I can achieve some significant performance gains by ensuring a specific geographic message path is followed.

I started down this path because I had to keep increasing rx1_delay in a US based CS server for EU devices using a US based MQTT broker. The devices would miss the LinkADRReq from the server and never get out of DR 0. I had to go up to rx1_delay=10 for ADR to work reliably, and the devices now communicate at DR 5.

The eu868 regional parameters spec recommends 1s for RX delay 1.

Performance info: The connection between the EU MQTT broker and my US CS server is 2-3x slower than the connection between an EU CS server and My App. Also, the connection between the EU broker and the EU CS server is 100x faster than between the EU broker and the US CS server.

I am using a hosted broker service running on AWS, but CS and My App all run in the same GCP VPC network. The EU CS server and EU MQTT broker use different cloud services, but likely are running in the same EU datacenter. Ping times between the two average a screaming 1.5 ms.