Bottleneck analysis
Nginx logs, the database slow query log and resource usage analyzed to find where the pressure really is before any server is added.
Servers & Hosting
High-traffic website hosting with load balancing and high availability
A campaign goes live, traffic multiplies, and the site falls over in exactly that hour. With server load balancing, traffic is spread across several machines and the architecture is designed so that one failed server does not take the whole service down. We start the design from your real traffic numbers and your budget.
Tools & technology
high-availability
- HAProxy
- Nginx
- Keepalived
- MariaDB Galera Cluster
- ProxySQL
- Redis
- MinIO
- k6
- Prometheus
6work areas
4deliverables
4steps
What is Load Balancing & HA?
Server load balancing is an architecture that spreads website traffic across several servers so the site stays up at peak times and one failed machine does not take the whole service down. It is for sites that slow down or return 503 errors during sales, run everything on a single server, or have a database that locks up under query load. PikoSystem first finds the real bottleneck from Nginx logs and the slow query log, then sets up HAProxy with health checks and two balancer nodes using Keepalived, configures MySQL or MariaDB replication with ProxySQL, adds Redis for sessions and object cache, and runs load tests with k6 plus a deliberate node shutdown to confirm failover. You receive an architecture diagram, a load test report with measured capacity, a failure runbook and configuration documentation.
When you need Load Balancing & HA
- During sales the site slows down or returns 503 errors.
- Everything runs on one server, and if it fails, work stops.
- The database locks up under query load.
- Upgrading the server means taking the site offline for hours.
What Load Balancing & HA includes
Load balancers
HAProxy or Nginx with health checks, and two balancer nodes with Keepalived and a floating IP so the balancer itself is not a single point of failure.
Database replication
MySQL or MariaDB replication (primary/replica or Galera Cluster), with read queries routed to replicas through ProxySQL.
Caching and sessions
Redis for sessions and object cache, page caching in Nginx or LiteSpeed, and static files served from a CDN.
Shared files
Uploaded files kept in sync across nodes with NFS, GlusterFS or S3-compatible storage such as MinIO.
Load and failure testing
Load tests with k6 or JMeter, and deliberately shutting down a node to confirm that failover actually works.
What you get from Load Balancing & HA
- An architecture diagram showing each server's role and the traffic path
- A load test report with measured capacity
- A runbook for node failure, database failover and adding a new server
- Configuration documentation for the load balancers, database and cache
Load Balancing & HA: a practical guide
Galera Cluster or primary/replica replication?
Primary/replica replication is simpler and runs on two servers, but it is asynchronous. A replica can lag by a few seconds, so a customer whose read query lands on it may not see the order they just placed. Promoting the replica when the primary fails also needs a defined tool or procedure.
Galera Cluster replicates synchronously and every node holds the full dataset, but it needs at least three nodes, or two plus garbd, to avoid split-brain. It works only with InnoDB tables and is sensitive to network latency, so nodes belong in one data center or on a low-latency link.
HAProxy or Nginx for server load balancing?
If Nginx already sits in front of your site, an upstream block in Nginx is the easiest first step. Its limitation is that open-source Nginx only has passive health checks, so it drops a failed server only after real user requests have hit errors.
The free edition of HAProxy runs active health checks against an endpoint such as /health, has a live statistics page, and can also balance MySQL or Redis in TCP mode. Layered designs often use HAProxy to distribute traffic and Nginx on each node for caching and static files.
Common server cluster mistakes
A health check that only confirms port 80 is open treats a node returning 500 errors as healthy and keeps sending it traffic. The health endpoint should touch the database and cache too. Scheduled jobs are another trap: when cron runs on every node, emails go out two or three times and reports are generated repeatedly.
Placing every node on the same physical server or virtualization host is also common, and one host failure then takes out the whole cluster. Anti-affinity rules in the hypervisor, or servers in different zones, reduce that risk.
High availability vs disaster recovery
High availability covers the failure of one component in the same location, such as a node shutting down or a disk failing. Disaster recovery is for losing the whole data center, the data itself, or your cloud account. A cluster with all three nodes in one data center offers no protection if that site goes dark or data is deleted by mistake.
Disaster recovery planning starts with two numbers. RPO is how much data you can afford to lose, and RTO is how long the service can stay down. Together they decide whether offsite backups are enough or you need a standby second site.
How Load Balancing & HA works
-
01
Measurement
We measure current traffic, peak patterns and bottlenecks to see where the problem really comes from.
-
02
Design
We propose an architecture with server count, cost and failure tolerance. Sometimes tuning the existing server is enough.
-
03
Phased build
Components are added one at a time and each phase is tested before the next, without moving the whole site at once.
-
04
Testing and handover
Load and failure tests are run, results are reported, and the runbook is handed to your team.
Load Balancing & HA: frequently asked questions
Does MySQL database replication replace backups?
No. Replication copies every change to the second server immediately, including an accidental table drop. To recover from human error or ransomware you still need independent, versioned backups.
Does a high-traffic site always need several servers?
Not always. On many sites, proper caching, query optimization and PHP-FPM tuning raise the capacity of the existing server noticeably. Multiple servers make sense when one server has hit its ceiling, or when even a short outage is unacceptable for the business.
Can this run on Iranian cloud providers?
Yes. HAProxy, Keepalived and database replication all run on virtual and cloud servers. The floating IP needs support from the data center or cloud provider, and sometimes the provider's own load balancer is the better fit.
How is the cost of high availability estimated?
There are two parts: the extra servers, and the design and build work. After measuring, we propose two or three options with different levels of failure tolerance, so you can weigh cost against risk.
Related searches
- high-traffic website server
- high-traffic hosting
- server high availability
- server cluster
- HAProxy setup
- website stability
- MySQL database replication
Related services
Quote
Tell us what you need, we'll come back with a plan and a price
A few lines on where things stand and what you want is enough. An engineer calls you back, not a sales rep.
- 01We read your request and call if anything is unclear.
- 02If needed, we do a quick remote review or a site visit.
- 03You get a written proposal with scope, timeline and cost.