back
7 comments
Do you think this problem could be solved by having the backend service randomly redistribute packets? That is, if each service kept/processed a percent of the packets and randomly forwarded the remainder to other 'backend' service computers.

Membership and status would be easy: are they forwarding random packets to me? Then they're up and running. New computer sends packets? New service member, so tell them about members you know of. This would also allow multiple public ingress points (like running multiple simple load balancers) so clients could change which computer they send to, and bandwidth would be ~balanced.

Interesting concept. I handled the bandwidth balancing by using multiple IPs in DNS, and latency-based routing.
Why are load balancers so popular in the first place?

I've never seen an architecture diagram for a high availability horizontally scalable system that included a generic load balancer.

When I give system design interviews, it's a bad sign of the interviewee adds a balancer. It ends up being a hand-wavy solution to difficulties on either side of the balancer.

You haven't seen many architecture diagrams, have you?
I've seen one particular one many times:

                   +---------+
  +--------+       |expensive|        +------------------+
  |internet+-------+  load   +--------+a bunch of servers|
  +--------+       |balancer |        +------------------+
                   +---------+
Ipvs offers round Robin load balancing at the l4 layer
It does, but seems to suffer some of the ills in the article[1]. I haven’t tried it, though and should to confirm.

[1] http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.UDP.h...