First off, speed is not scalability. I think we need to start talking about "scalability" in terms of the "speed" / "cost". I can get billions of req/sec if I have billions of dollars. What scalability should be is getting as much as you can performance/stability wise with the least amount of money.
With that being said, the plan is that since all backends and frontends can talk using arbitrary types of 0MQ sockets, and 0MQ provides for any kind of network layout, you can make it as "no single point of failure" as you have money to burn on. In my tests so far it's incredibly trivial to have 10 mongrel2 servers submitting requests using a subscribed UUID, and then have 20 backends servicing those requests and replying as needed. Since both the frontends and backends are just using basic messaging with subscribed queues it's fairly easy to get them to talk without any one of them being the point of failure.
Of course, with this comes a configuration penalty which I have to figure out. Either the backends then have to know where all the frontends are (probably easiest) or the frontends have to know about backends. I still haven't got that worked out, but again, it's fairly trivial to create a "registration" service where newly minted backends/frontends announce themselves.
Finally, all of these things have been solved no problem. The easiest answer is I'll just figure out how other people have done it and copy them. It's not like this is new territory or anything. The question itself is kind of stupid because you're saying, for some reason, 0mq precludes my ability to use any existing best practice architecture, when really they're orthogonal and I'm not just using 0mq.
With that being said, the plan is that since all backends and frontends can talk using arbitrary types of 0MQ sockets, and 0MQ provides for any kind of network layout, you can make it as "no single point of failure" as you have money to burn on. In my tests so far it's incredibly trivial to have 10 mongrel2 servers submitting requests using a subscribed UUID, and then have 20 backends servicing those requests and replying as needed. Since both the frontends and backends are just using basic messaging with subscribed queues it's fairly easy to get them to talk without any one of them being the point of failure.
Of course, with this comes a configuration penalty which I have to figure out. Either the backends then have to know where all the frontends are (probably easiest) or the frontends have to know about backends. I still haven't got that worked out, but again, it's fairly trivial to create a "registration" service where newly minted backends/frontends announce themselves.
Finally, all of these things have been solved no problem. The easiest answer is I'll just figure out how other people have done it and copy them. It's not like this is new territory or anything. The question itself is kind of stupid because you're saying, for some reason, 0mq precludes my ability to use any existing best practice architecture, when really they're orthogonal and I'm not just using 0mq.
tl;dr: The way everyone fucking does it.