Multi-region has a reputation for being complex. Most of that comes from keeping data consistent across regions, a requirement Trinity Guard doesn't have. Here's what we built instead, and where the approach stops working.
Multi-region has a reputation for being expensive and complicated. Much of the writing about it is about distributed databases, replication lag, conflict resolution, and what happens when three regions disagree about the same record.
All of that is real. None of it applied here.
Trinity Guard, a patrol verification platform we've been building since 2022, runs in three separate environments across three continents. Extending it to multiple regions took about a month.
That isn't because the work was trivial. It's because of a decision made early that removed the hardest part rather than solving it.
The short version
- Three environments: AWS US East (Virginia), AWS South America (São Paulo), and a dedicated server in Budapest
- No application data replicates between them. Each environment has its own database and its own users
- One codebase, no region-specific forks. Regional differences are handled through configuration.
- Rollouts happen region by region, not simultaneously
- The same architecture makes on-premise deployment possible for organizations that require it
- Build time: roughly one month
The decision behind all of it: the product has no requirement for users in one region to access data from another.
The question that determines everything
Before any infrastructure decision, one thing needs answering: does a user in one region ever need data from another?
For many products, yes. A global marketplace where a buyer in Germany purchases from a seller in Brazil needs a shared view of listings and transactions. A collaboration tool with teams across continents needs the same document available everywhere. Those products have a genuine distributed-state problem, and that's where most of the difficulty in multi-region work comes from.
Trinity Guard is not that product.
A security company operating in Texas has no reason to see patrol records from a company in Hungary. The data is operational, site-specific, and belongs to one organization in one place. There's no shared catalog, no cross-border transaction, no global view anyone needs.
Once that's established, the architecture follows. Each region runs its own complete instance with its own application database. Nothing replicates because nothing has to.
This is the decision worth spending time on. Not which database supports multi-region writes, but whether you need them. A surprising number of products that assume they do, don't.
Why one of the three isn't AWS
Two environments run on AWS. The third, serving Europe, runs on a dedicated server in Budapest.
The reason is specific: AWS has no Hungarian region, and a significant share of the European user base is Hungarian companies. A dedicated server in Budapest puts the service closer to them than any AWS region would.
This looks inconsistent on an architecture diagram and is reasonable in practice. Uniform infrastructure is worth something: one set of tooling, one operational model, one vendor relationship. But it isn't worth more than the thing the infrastructure exists to deliver.
Because the environments don't replicate application data between them, we could choose infrastructure per location without adding cross-provider replication to the system. That's not the same as saying it's free: each environment still needs provisioning, monitoring, backups, security updates and a recovery plan. Running three of them is real operational work. What isn't there is the class of problem that comes from keeping them consistent with each other.
Isolation is what buys the flexibility. In a synchronized architecture, adding a non-AWS environment means solving replication across providers. Here it means running the application somewhere else.
How a user ends up in the right place
The routing is deliberately simple.
On the web, a new customer selects their region during registration, and their account is created there. Their organization's application data is stored in that environment's database.
The mobile app then routes users based on what their administrator configured. A guard opening the app doesn't choose anything. It connects to the environment their organization belongs to.
There's no automatic geographic routing, no latency-based selection, no failover between regions. An organization belongs to one environment, and that's deliberate rather than a limitation.
One codebase, three deployments, staged rollouts
All three environments run the same codebase, with no region-specific forks. Regional differences are handled through configuration rather than separate code forks.
This matters more than it sounds. Separate regional codebases would add another maintenance problem: keeping fixes and features aligned. One region gets a fix the others don't. A feature ships in one place and gets backported badly. Eventually nobody is certain what's running where.
Updates go out region by region, not everywhere at once. A new version reaches one environment, runs there, then moves to the next, which means they may temporarily be on different releases. If something is wrong it affects one set of users, and rolling back means reverting one environment.
Staged rollouts are possible in synchronized architectures too, but they require handling compatibility between instances running different versions while exchanging data. Regional isolation removes that coordination problem: the environments don't exchange application data, so version differences between them don't have to be managed.
The same architecture made on-premise possible
Some organizations can't put operational data on infrastructure they don't control. Depending on the sector and the country, that's either a strong preference or a hard requirement.
Trinity Guard supports this: the platform can be deployed on a customer's own servers, with the application and database running in their environment. That gives the organization control over hosting and access.
This didn't require a separate product. An on-premise deployment is structurally the same thing as a region: a complete, independent instance of the same application. The architecture that made three environments straightforward made a fourth deployment shape possible without redesigning anything.
Updates work differently there. We provide the new version; the customer's own team applies it on their schedule. That's appropriate: an organization that requires self-hosting generally also wants control over when its systems change.
What isn't isolated
The three environments don't replicate application data between them. Regional isolation here refers to the application deployments and their databases. It does not mean that every external service used by the platform is hosted separately in each region.
External services such as payment processing, email delivery, or error reporting can still introduce shared dependencies. What matters is whether a problem with one of those services could affect multiple environments.
When this approach doesn't apply
If the product needs cross-region data access, this model needs additional design. How much depends on what "access" means: occasional reporting across regions is a different problem from shared records, which is different again from data that multiple regions update concurrently. The first might be solved with a separate aggregation path; the last is a genuine distributed-state problem.
If you need automatic failover between regions, isolation doesn't provide it. Each environment's availability is its own.
If you have global analytics requirements, you'll need a deliberate path to aggregate data that doesn't otherwise move.
And if your users are concentrated in one place, you may not need multiple regions at all. The reasons to have them are proximity to users, data residency requirements, and redundancy. If none apply, one environment is simpler.
What to decide before you build
Three questions worth answering early, while they're still cheap to answer.
Does any user need data from another region? This is a key architectural decision. If not, the problem is simpler. If so, distinguish between reporting, shared records, and concurrent updates, because each comes with different requirements and costs.
Is your data naturally partitioned by organization? B2B products where each customer's data is self-contained partition cleanly. Consumer products with social features usually don't.
Might a customer eventually require self-hosting? If it's plausible, build as if each deployment is independent from the start. Retrofitting that into a system with a central service is one of the more expensive changes in software.
None of these require building multi-region support on day one. Considering them early can help you avoid architectural decisions that make regional deployment or self-hosting harder later.
Working out what your infrastructure needs to support?
Tell us where your users are, what the data residency requirements look like, and whether anything needs to be shared between regions. We'll tell you which version of the problem you actually have.
