Solution 1:

One useful benefit of "L7" like haproxy is being able to use cookies to keep the same browser hitting the same backend server. This make debugging client hits much easier.

L4 balancing may bounce a single user around on several backend servers. (which in certain cases may be advantageous, but in a debugging/profiling sense, using "L7" is much more valuable.)

EDIT: There's also a potential speed advantage of using HTTP balancing. With keep-alives clients can establish a single TCP session to your balancer and then send many HITs without needing to re-establish new TCP sessions (3-way handshake). Similarly many LBs maintain keep-alive sessions to back end systems removing the need to do the same handshake on the back end.

Strict TCP load balancing may not accomplish both of these as easily.

/* FWIW: I wouldn't say "L7" or "L4", I would say HTTP or TCP. But I'm a stickler for avoiding using the OSI to describe things it doesn't match up with well. */

I think fundamentally if you're not sure what to deploy, go with what feels simple and natural to you. Test it (use apache bench?) and make sure it works for your needs. To me HTTP LB is more natural.

Solution 2:

Given the lack of advantage to you from doing L7 balancing, I'd settle on L4 balancing instead. I'm a big fan of keeping it as simple as possible, without sacrificing too much.

L7 requires the balancers to inspect the http headers in the packets that are going through them for appropriate routing, adding additional overhead and a marginal increase in latency for the end user. It seems a pointless expense to me if you'll gain nothing by it.