Web Hosting for Companies: An Architecture for Each Stage

Two companies’ websites go down for two hours on the same day. One is a small bookshop in Salmiya; it loses a few orders that come back the next morning. The other is a pharmaceutical distributor serving hundreds of pharmacies; it loses a full day of orders and the trust of customers it promised delivery times to. Same incident, completely different cost. That’s why headcount doesn’t decide a company’s hosting. Three numbers do: how many minutes your site can afford to be down, how long it may take to come back, and how much data you can afford to lose. In this article we work out those numbers, then build, for each stage of a company, the architecture that meets them, without paying for what you don’t need.

01Three numbers before any plan

Before you compare plans, write these numbers on a single page and agree on them with management:

• Availability target: The share of the month your site must stay up, such as 99.9% or 99.99%. It usually appears in the service level agreement you sign with your provider, or the one you promise your own customers.
• Recovery time (RTO): The recovery time objective is the longest acceptable gap between a failure and service coming back: four hours for a brochure site, fifteen minutes for a platform your customers work in all day.
• Recovery point (RPO): The recovery point objective is the most data you can afford to lose, measured in time. A nightly backup means you could lose up to 24 hours of orders and edits.

To set these numbers realistically, price an hour of downtime: the revenue that flows through the site in a peak hour, the wages of the team that stalls with it, and any penalties you owe if you break a promise to customers. That figure is the ceiling on what it’s worth spending each month to prevent downtime.

02What availability percentages mean in minutes

The percentages look close together, but the gaps are large once you turn them into minutes. Here is the downtime allowed in a 30-day month (43,200 minutes) and in a full year:

Remember that your site is a chain of components: DNS, then the application server, then the database, and perhaps an external payment gateway. If any one of them failing takes the whole site down, the site’s availability is the product of their percentages. A server with a 99.97% guarantee, a database on another server with the same guarantee, and DNS at 99.99% give you about 99.93%, or roughly 30 minutes a month, not 13. Put your own components’ figures into this line and work it out:

# Availability of a chain of three components: server, database and DNSawk 'BEGIN { a = 0.9997 * 0.9997 * 0.9999; printf "%.2f%%  %.1f min/month\n", a * 100, (1 - a) * 43200 }'

What the guarantee doesn’t tell you

• It measures the provider’s infrastructure, not your application: if your site stops because of a broken plugin or a disk full of logs, the server is still “up” as far as the agreement is concerned.
• It usually excludes scheduled maintenance announced in advance, so read how often it happens and at what hours.
• Compensation is a service credit taken off your invoice; it doesn’t make up for lost sales.

CoreVPS servers, for example, carry a 99.97% uptime guarantee, about 13 minutes in a 30-day month. That’s the infrastructure figure; your application’s availability is built on top of it by the choices you make.

03Stage one: a small company

A brochure site or a store with a few dozen orders a day, email for a handful of staff, and no engineer dedicated to servers. Here a 99.9% target is enough, with an RTO of a few hours and, usually, an RPO of one day. The real risk at this stage isn’t a technical failure; it’s having no copy to restore from, and a single password known by an employee who has left.

• Shared cPanel hosting: The provider runs the server and its updates; you run your site from the control panel. Illevante’s cPanel Start, Power and Infinity plans handle about 35,000, 75,000 and 150,000 visits a month, with an SSL certificate that renews automatically and backups kept for 15, 30 and 45 days depending on the plan.
• Separate managed email: cPanel plans include unlimited email accounts, which is enough to start. But if email is your main sales channel, moving it to a dedicated service, such as business email from Acrux Mail, means a site outage doesn’t stop your mail, and vice versa.
• The domain in the company’s name: Register the domain to the company, with an admin address that isn’t tied to one person, and turn on two-factor authentication in the client area.
• A copy outside the provider: Download a full backup of your account once a month and keep it on storage the company owns. The provider’s backups protect you from failures; yours protects you from losing the account itself.
• External monitoring: Sign up for an uptime check that requests your home page every one to five minutes and alerts you by email or phone. Knowing about an outage before your customers do cuts half the recovery time.

And don’t buy a virtual server at this stage unless someone will patch and watch it: an unpatched server is more dangerous to a small company than shared hosting its provider manages.

04Stage two: a medium-sized company

A store that sells every hour, a SaaS app with a few hundred users, or an agency hosting its clients’ sites, with at least one developer or sysadmin. The target here is about 99.95%, an RTO between one and four hours, and an RPO of an hour or less. We cover the move from shared hosting to a VPS step by step in a separate article on the blog; here we focus on what the architecture looks like afterwards:

• One server for the app, another for the database: Moving the database to a second VPS stops a heavy query from choking the web server, lets you upgrade each one on its own, and keeps the database off the public internet: only the application server can reach it, through the firewall.
• A content delivery network: A CDN in front of the site serves images and static files from points close to visitors, taking load off your server and shortening load times in cities far from the data centre.
• Monitoring and alerts: An uptime check alone isn’t enough: watch CPU, memory, disk usage and p95 response time, and set the alert to fire before the disk fills, not after. CoreVPS servers include Grafana, Prometheus and Zabbix among the ready apps you can install at creation.
• A staging environment: A scaled-down copy of production where you try updates before you ship them. Most outages at this stage are caused by an update, not by a hardware failure.
• Two layers of backup: A full server backup every night and a database backup at least every hour, both off the server. Every CoreVPS plan comes with external backup space of 10 to 100 GB, depending on the plan.

A backup you’ve never restored is only a hope. This is a drill you run once a month on the staging server, and it gives you your database’s real RTO in minutes:

# These commands assume your MySQL credentials are stored in ~/.my.cnf# On the production server: a consistent dump of InnoDB tables without locking themmysqldump --single-transaction --routines --triggers souq_db | gzip > /backup/souq_db-$(date +%F-%H%M).sql.gz# Ship the backups to a backup server in another data centrersync -az /backup/ [email protected]:/srv/backups/souq/# On the staging server: fetch the backups, restore the newest one, and time itrsync -az [email protected]:/srv/backups/souq/ /restore/mysql -e "CREATE DATABASE IF NOT EXISTS souq_staging"time (gunzip -c "$(ls -t /restore/souq_db-*.sql.gz | head -1)" | mysql souq_staging)

If the restore takes 40 minutes, don’t promise management a 15-minute RTO. Here the RPO equals the gap between two backups; if you need less than an hour, the answer is transaction logs and point-in-time recovery, which we detail in our article on database hosting.

05Stage three: a large company

A platform with thousands of concurrent users, contracts that promise your customers an availability figure and penalties, and regulators asking where your data lives and who can reach it. The target is 99.99%, or 4 minutes a month, with an RTO under 15 minutes and an RPO measured in seconds. A bigger server won’t get you there; an architecture with no single component that takes the service down when it fails will:

• Several app servers behind a load balancer: Load balancing spreads requests across two or more servers and pulls a failed server out of rotation automatically, so you can roll out updates one server at a time without downtime. The load balancer itself needs a second instance that takes over its address if it fails.
• A replicated database: Replication keeps a standby server that receives every change from the primary. Asynchronous replication is faster but may lose a few seconds of writes on failover; synchronous replication makes the RPO zero at the cost of slower writes. Choose according to what you’ve promised.
• Backups in a second region: Replication copies mistakes too: a table dropped by accident is gone from both copies within a second. So independent backups remain essential, kept in another data centre. With CoreVPS, for example, you run production in Germany and keep backups and the recovery site in Finland, so the data stays inside the European Union.
• Compliance: Know which laws your data falls under: GDPR if you serve residents of the EU, and PCI DSS if card data passes through your servers; the simplest way out of PCI scope is to leave the card to your payment gateway and never store it. Turn on audit logs for every administrative access, multi-factor authentication, and backup encryption.
• Recovery drills: A recovery plan that’s never been tested is just paper. Deliberately stop the primary server in staging at least twice a year, and measure how many minutes the failover took.

06Decision table by stage

Here are common mistakes at every stage, and what lies behind them:

ProblemWe promised customers 99.99% because our server is guaranteed at 99.97%

FixYour site’s availability is the product of its components, so it’s lower than the weakest link. Don’t promise more than you’ve actually measured over three months.

ProblemThe backups exist, but the restore took a whole day

FixTest restores monthly and time them, starting with the database, since it’s the slowest and the most important.

ProblemThe backups are stored on the same server

FixA disk failure or a compromised server takes the backups with it. Move them to separate storage, preferably in another data centre.

ProblemThe site slows down, so we buy a bigger server every few months

FixSplit out the database and add caching and a CDN first. Vertical scaling alone postpones the problem and makes every upgrade more expensive.

07Before you decide

Start from the numbers, not the plan: price an hour of downtime, write down the RTO and RPO you can live with, then choose the smallest architecture that meets them. Redo the sums every six months, or whenever the revenue flowing through the site doubles.

The practical rule for moving up is simple: once an hour of downtime costs more than a month of the next stage’s architecture, you’re already late. Until then, spend on tested backups and monitoring before any extra server; they’re the cheapest way to cut recovery time.