We've done this before, but by adding an additional load-balancer that forwards requests to a different port (e.g. 81 instead of 80) depending on the subdomain that was accessed. The request is processed by nginx, which has separate server blocks and associated upstreams for processing requests that come in over the configured ports. The only application logic that was necessary to accommodate the changes was a check to determine if the user should be part of the beta, and redirect them to the appropriate subodmain if necessary.
While it's not as clean as having the check done in nginx itself via Lua script + Redis, it's relatively low friction. That said, the Lua script embedded in the nginx config is very slick, and I had been contemplating writing something similar using the nginx memcache module. Nice work.
Yes that works too as I mentioned in the first couple of paragraphs of the post.
However having a beta.mixlr.com domain a) introduces a lot of friction and seriously reduces the ease with which you can test features b) may alter the perception or expectations of a visitor, making testing less valid.
We've got a lot of users and we want to make the roll-out process completely transparent and inclusive.
While it's not as clean as having the check done in nginx itself via Lua script + Redis, it's relatively low friction. That said, the Lua script embedded in the nginx config is very slick, and I had been contemplating writing something similar using the nginx memcache module. Nice work.