Spreading across locations
Running in two places protects you from losing one. It also doubles the moving parts and introduces the one thing a single site never has to think about: the distance in between. Worth it — when you do it for the right reason.
A second location buys you one specific thing: survival of losing the first. That is valuable — but it is not free, and it is not the answer to every reliability problem. Most outages are not whole-site failures, and a second site does nothing for a bug in your code.
What a second site protects against
- Loss of a whole facility — rare, but total when it happens
- Regional network trouble reaching one location
- Maintenance that would otherwise be user-visible
What it does not fix
A second site does nothing for a bad deploy, a corrupted database, or a logic bug — those replicate cheerfully to both places. Single-server problems are better solved by a second server or good backups first. Reach for a second location when the facility itself is the risk you are removing.
The hard part is data
Stateless front-ends are easy to run in two places; the database is where it gets real. Keeping data consistent across sites means either accepting replication lag — see replication — or taking on the complexity of synchronous replication across distance, which the speed of light makes expensive. This, not the servers, is the actual project.
Distance is latency
Two sites are only as close as physics allows. Anything chatty between them pays that round-trip every time — see latency and bandwidth. Design so the two sites are loosely coupled, not constantly talking.
Simpler steps first
Before two sites, a warm spare, tested restores and a second server within one location remove most of the pain for a fraction of the effort. Go multi-site when the cost of losing a whole location — see what downtime actually costs — clearly justifies it. Tell us the goal and we will help you reach it by the shortest route.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base