Databases3 min read
Backups you have actually tested: RPO, RTO and point-in-time recovery
You do not have backups. You have restores — and you only know whether you have those if you have done one this quarter.
Multi-region architecture serves two distinct goals: lower latency for geographically distributed users, and survival of a regional outage. Latency is often solved more cheaply with a CDN and edge caching; true multi-region resilience requires data replication, failover automation and regular testing, and adds substantial complexity to writes.
| Goal | Cheapest sufficient solution |
|---|---|
| Static assets slow globally | CDN — solved |
| Pages slow globally | Edge caching of HTML, static generation |
| Reads slow globally | Regional read replicas |
| Writes slow globally | Multi-region writes — genuinely hard |
| Survive a region outage | Active-passive with tested failover |
| Survive with zero downtime | Active-active — most expensive |
Work down that list and stop at the first row that solves your actual complaint. In most audits, the requirement stated as 'we need multi-region' is satisfied by the first two rows.
The failover that has never been tested is the one that fails. Schedule a game day, shift traffic deliberately, and measure how long it took and what broke.
No. Multiple availability zones within one region protect against a data centre failure and are usually cheap and easy — enable that first. Multi-region protects against an entire region failing and is far more complex.
Read replicas, easily. Multi-region writes require either a distributed SQL database designed for it or careful partitioning by region, with real trade-offs in latency and consistency.
They reduce latency for logic that does not need your primary data. If the request must read your database, the round trip to the data region still dominates.
At least twice a year, in production, as a planned exercise. Anything less and configuration drift will have quietly broken it since the last test.
Harshal Patel
Founder & Lead Engineer, ROVQIX
Harshal leads engineering at ROVQIX, where he has shipped production Next.js, Node.js and PostgreSQL systems for startups, SaaS teams and ecommerce brands. He writes about the trade-offs behind architecture decisions rather than the framework of the week.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
You do not have backups. You have restores — and you only know whether you have those if you have done one this quarter.
Putting a CDN in front of a site does nothing by itself. The cache headers you send decide whether it helps or just adds a hop.
You cannot debug what you cannot picture. This is the map of a production request, layer by layer.
No spam. Just the occasional case study and craft breakdown.