High Availability: The Architecture That Handles the Load
By The Atlas Hoster team4 min read
One server = one single point of failure
A website hosted on a single server relies on a single machine. If it goes down, the site goes down with it: this is known as a single point of failure. For a brochure website, the risk may be acceptable; for an online store or media outlet, every minute of downtime costs sales or readers.
High availability hosting addresses this problem by eliminating the single point of failure: multiple servers work together, and the failure of one has no impact on users. This is an architecture, not a more powerful server. A larger server delays the problem; a redundant architecture solves it. This distinction is essential when choosing between a large VPS and true redundancy.
Load balancer and redundant web servers
The entry point for such an architecture is the load balancer, such as HAProxy or NGINX. It receives all traffic and distributes it across several identical web servers. It performs three essential functions: it distributes the load, removes a server that is not responding (thanks to regular health checks), and terminates the TLS encrypted connection before forwarding the request.
Behind it, two or more identical web servers, deployed via automation, serve the same site. The failure of one goes unnoticed, and an additional server can be added to absorb a spike. It is this redundancy that makes the difference with a single VPS: capacity scales horizontally, machine by machine, rather than hitting the limits of a single server.
Replicated database
A database does not duplicate itself like a web page. Replication involves designating a primary server (the source) that records writes, and one or more replicas that receive a copy of these changes. This principle has been documented for a long time: the source server logs its modifications, and the replicas apply them to stay up to date.
In a high availability architecture, the primary and replica are monitored, and failover from one to the other is tested in advance. Your data thus survives the failure of a database server, which is the most feared scenario. Replication also provides a second benefit: read operations can be offloaded to the replica, reducing the load on the primary.
Application cache and CDN
Not everything should reach the servers. The application cache (Redis or Varnish) absorbs repeated reads: sessions, shopping carts, pages, query results. The less the database is stressed, the better the overall system handles the load. Upstream, the CDN serves pages and images from servers close to visitors and filters attacks and bots.
At Atlas Hoster, the reference architecture places a CDN and an application firewall in front of everything, followed by the load balancer, web servers, cache, and replicated database. Each layer has a specific role and a control point. This stratification is what allows handling a spike without rebuilding everything.
Backups and restoration
Redundancy is not a backup. Replication can propagate an error (an accidental deletion, corruption) to the replica. Therefore, verified backups and a documented restoration procedure are required. This is the ultimate safety net: if everything else fails, you restore.
A best practice is to test restoration regularly, not just run backups. A backup that has never been restored is an unfulfilled promise. To learn more about the method, consult our guide creating a backup copy, and for protection against abusive access, our guide blocking an IP address or domain.
When high availability hosting is justified
High availability costs more than a VPS because it involves multiple machines and operational expertise. It is justified when an outage has a direct cost: online store, media, business application, promotional period, or launch. For a low-traffic brochure website, shared hosting or a well-sized VPS is sufficient.
The criterion is not size, but the impact of an outage. If an hour of downtime costs you more than several months of redundant architecture, the decision is already made. Conversely, over-sizing a small site is a waste of resources. Consider this example: a store that generates a significant portion of its revenue during a promotional week cannot afford an outage on that day. The additional cost of a redundant architecture, spread over the year, becomes negligible compared to the risk. On the other hand, a low-traffic blog has nothing to gain from multiplying servers.
Audit, deployment, and load testing
A high availability architecture cannot be improvised. It begins with an audit of the existing setup, continues with design and quotation, then deployment and migration. Finally, and most importantly, it is validated through load testing before customers arrive: simulating a spike allows you to discover failure points and correct them before Day J.
Atlas Hoster designs, deploys, and manages these architectures, and tests them under load before going live. To understand the mechanics of these tests, read our article on load testing, our article on high-traffic media, and our article on SLAs.
If your business cannot afford to stop, discover our high availability architectures.
FAQ
High availability and backup, are they the same thing? No. Redundancy protects against hardware failure; backup protects against data loss (deletion, corruption). You need both.
How many servers are needed at a minimum? Generally, one load balancer (or a redundant pair), two web servers, and a primary database with a replica, totaling several machines. The exact number depends on the load.
Can a powerful VPS replace high availability? It delays the saturation point but remains a single point of failure. To tolerate failure, you need redundancy.