Load Balancing
Load balancing is the automatic distribution of incoming requests across multiple servers so that no single one is overloaded. In ERP operations, load balancing keeps response times consistent and improves resilience, because failed servers are removed from the distribution.
Load balancing refers to the automatic distribution of incoming requests across multiple equivalent servers or instances, so that no single machine becomes overloaded. An upstream component, the load balancer, receives all requests and forwards them according to defined rules to the server best suited at that moment. This stays invisible to the user: they call a single address, while behind the scenes a cluster of several machines does the work.
In the ERP context, load balancing is the technical foundation that keeps a system fast and stable even with many concurrent users, high document volume or seasonal load peaks. It is closely tied to scalability and high availability: only by distributing the load can several servers be operated in parallel in a meaningful way, and if one server fails, the others take over without interruption. Load balancing is therefore not an added convenience but a core building block of professionally operated cloud and on-premise systems.
At a glance
- Automatically distributes incoming requests across multiple servers so none is overloaded
- Foundation for scalability and high availability in ERP operations
- The load balancer can be a hardware appliance or software (e.g. a reverse proxy)
- Distribution methods include round robin, least connections, weighted distribution
- Health checks automatically remove failed servers from the distribution
How does load balancing work?
A load balancer sits logically between the users and a group of equivalent servers running the same application – often called a server pool or backend pool. Every incoming request first hits the load balancer, which decides on the basis of a distribution method which server handles it. The goal is the most even utilisation possible: no server should be under full load while another has nothing to do.
To ensure that distribution only goes to functioning servers, the load balancer continuously monitors the backends with so-called health checks. If a server does not respond or returns errors, it is automatically removed from the distribution and only added back after a successful check. For applications with session state – such as a logged-in ERP interface – session persistence (sticky sessions) additionally ensures that a user’s follow-up requests land on the same server.
Distribution methods (algorithms)
The simplest method is round robin: requests are distributed to the servers in turn. Least connections routes the next request to the server with the fewest open connections – useful when requests take varying amounts of time. With weighted distribution, more powerful servers receive a larger share. IP hash assigns a user to a fixed server based on their address. Which method fits depends on the application profile; modern load balancers can be finely configured here.
Layer 4 vs. Layer 7
A Layer 4 load balancer distributes at the transport level based solely on IP address and port, without knowing the content of the request – this is fast and resource-efficient. A Layer 7 load balancer works at the application level and can evaluate the content, for example the requested URL or headers. This allows requests to be steered by content, for example directing API calls to different servers than the web interface. Layer 7 is more flexible but more demanding; in practice both levels are often combined.
Why load balancing matters
Without load distribution, a single server bundles all requests. As load rises – more concurrent users, a marketplace sale, a nightly import – response times grow until the system becomes noticeably slow or breaks down entirely. Load balancing decouples the load from a single machine: additional servers in the pool take over part of the requests, so that response times stay stable even as demand grows.
The second major benefit is resilience. When load is spread across multiple servers, the failure of a single one is no longer a total outage – the remaining servers carry the requests onward. Load balancing is therefore a prerequisite for high availability and for the uptime guaranteed in an SLA. A third advantage is easier maintenance: servers can be taken out of the distribution one by one, updated and returned, without users noticing any interruption (rolling updates).
Load balancing in the ERP system
An ERP system is rarely a single process. Web interface, application server, database, background jobs and interfaces often run in a distributed manner. Load balancing is typically placed in front of the application servers, so that the interactive load of many users and the machine load from API calls are distributed across several instances. This is especially decisive in e-commerce, because shops, marketplaces and shipping providers send requests through the interfaces around the clock.
With cloud and SaaS ERP, the provider handles load balancing in the background; the customer notices it at most through stable response times during peak season. Anyone operating an ERP on-premise or in their own cloud plans the load distribution themselves – as part of the operating architecture together with database replication and backup. Note that not every component scales horizontally at will: the central database is often the limiting factor, which is why load balancing usually applies at the application layer while the database is secured separately.
Distinction: load balancing, high availability and scalability
Load balancing is often conflated with related operational terms, even though it serves its own purpose. Scalability describes the ability to grow along with rising load – load balancing is the means by which several servers can even carry load together. Without load distribution, additional hardware would remain useless, because the requests could not be split up in a meaningful way.
High availability means that a system is reachable as continuously as possible. Load balancing contributes to this by bypassing failed servers, but it is not the same thing: high availability additionally encompasses redundant databases, data centres and network connections. A related term is failover – the automatic switch to a standby system. Load balancing works permanently in normal operation and actively distributes, whereas pure failover only kicks in when a fault occurs. In practice all three concepts interlock and together form a resilient operating architecture.
Load balancing in the German-speaking SME sector
For mid-sized companies in Germany, Austria and Switzerland, load balancing is relevant above all when switching to digital sales channels. A growing online shop or the connection of several marketplaces increases request volume sharply – a single server then quickly reaches its limits. Anyone using cloud ERP does not have to handle the technical distribution themselves, but should check in the contract what availability and what response times are guaranteed.
When operating in your own or a rented data centre, the question of data residency arises: server pools and load balancers are then ideally located in data centres within the EU, in order to meet data protection requirements. For companies without their own IT team, load balancing is usually an argument for a hosted or SaaS model, where the provider handles load distribution, health checks and maintenance and stands behind it in their SLA.
Example
Practical example: online retailer keeps response times stable during a sale
A retailer of household goods runs its ERP together with a connected online shop and two marketplaces. In normal operation, a single application server is enough for the roughly 40 employees and the ongoing interface calls. For the annual discount weekend, however, not only the number of orders rises but also the number of simultaneous stock and price queries from the marketplaces.
Because a load balancer is placed in front of the application servers, the load is automatically distributed across three instances. The users in the warehouse and customer service keep working without noticeable delay, while the API calls of the channels are served in parallel. When one server fails during the weekend due to an error, the load balancer removes it from the distribution within seconds thanks to a health check – the remaining two servers take over without any orders being lost or users noticing a disruption.
Frequently asked questions
Matching ERP systems
Related services
Questions about Load Balancing in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.