Research leads me to believe the most common architecture for a multi-instance (horizontally-scaling) message relay service (the typical example being an instant messenger/chat service) is to distribute client connections among the instances via some load balancing strategy. The instances hosting the clients wishing to converse then communicate internally (discovering each other (e.g. via common database or peer-sharing across a mesh) and communicating directly, or messaging through a common broker). Rough diagram of typical architecture:
Why incur the extra, ongoing load of the inter-instance communication for the duration of the session when instead the load-balancer/router could initially route both clients to the same instance? The router would make the same database lookups that an instances would have in the former scheme, and you would save a connection between instances (or in the case of a shared broker, two connections and the consideration of scaling the message queue as well), while decreasing end-to-end transmission delay.
Is this architecture common, and I just haven't read about it, or does it have a downside?