This is perfectly reasonable, and not too uncommon. I'll just throw out a few observations:
1. Each pool should only contain servers for a specific service. So if the request is for "/service/service1", for example, you'd send that request to the ONE pool that can service that request.
2. HTTP classes are deprecated in11.4. You're probably okay for now on your current version, but that'll eventually change. I'd recommend an iRule-based alternative. Something like the following:
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::uri]] {
"/service/service1*" { pool esb_pool_1 }
"/service/service2*" { pool esb_pool_2 }
"/service/service3*" { pool esb_pool_3 }
default { default_pool }
}
}
The default_pool is some pool that you've defined for any traffic that doesn't meet the other criteria, or you can simply close the connection. The above also assumes that everything within a service will live within this URI pattern.
3. Because you're using pools and monitors, you have an opportunity to very easily scale the services (add multiple servers to each pool for redundancy) - if you haven't already thought of that. Otherwise you need to consider what may happen if that one server (or all servers in that pool) become unavailable. Do you close the connection? Do you send some static "maintenance page" HTML? Do you redirect to some other page or site?