vijayjayaram

Author here. Great points, I agree 2 extra round trips are not strictly necessary.

The advantage of P2C is the simplicity that comes from its stateless/just-in-time nature. If you cache load, either by servers broadcasting or including a load indicator in the response, you have to consider cache invalidation and TTLs. The longer the TTL, the higher the odds of a thundering herd (all clients think one server is under loaded and proceed to overload it). If you're undertaking this complexity, it may be better to go with a proxy, which can have other benefits too (connection pooling, no client cooperation required). Like all such decisions, it depends on the situation.

Good question! Yes, it's in the interest of clients to cooperate.

Fundamentally, P2C thickens the interface between client and server by leaking the implementation and responsibility of balancing server load onto the client. Again, this works really well if there is a small, static set of clients as we have internally, but not that well if the clients are out in the wild (eg: on mobile devices). It's totally in the client's interest to upgrade, but that's always work and you just can't rely on that. :)

So imo this is a serious tradeoff that must be made before employing P2C. A good hybrid approach (briefly mentioned in the post) is to introduce a proxy that uses P2C. This is fully in your control and is cheaper than having the proxy maintain a full histogram of load on all downstreams.

I'm the author of this post, happy to answer any questions!