You can't talk load balancing without considering failover scenarios. Because a load balancer often is the single point of entry into your Web infrastructure, you need a backup load balancer to pick up the slack when your primary device fails. Beware, though, that adding a second device means deciding on yet another configuration.
The two main configurations for load-balancing failover are active-active and active-standby. In an active-active failover configuration, two load balancers can service requests for the same IP address. That means your Web infrastructure can serve more clients simultaneously, and latency is reduced in the failover process.
In an active-standby configuration, one load balancer is responsible for serving requests, and a secondary device takes over when the first one fails. When the standby load balancer steps in after a failure, it assumes the primary device's IP and MAC addresses, and handles all requests until the primary device is restored. The trade-off with this approach is that the failover process can take several seconds, during which time any incoming requests for Web content could get rejected.
When a failover does occur, the sessions are handled in one of two ways: stateful or stateless. Stateful failover is more reliable because when a load balancer fails, no TCP or Web sessions are lost. That's because the session table gets synchronized with the secondary device (in the active-standby model), or both devices are synchronized (in the active-active model). Stateful failover requires more hardware because mirroring sometimes decreases the number of concurrent sessions a device can handle.
Stateless failover, meanwhile, doesn't save existing sessions during the transition from a failed load balancer to a backup device, but it does re-establish those connections with the backup load balancer. So should you go stateful or stateless? That depends on how important in-progress TCP or Web sessions are to your business.