Yes, this is possible and a number of news and media agencies work with similar approaches in WordPress.
What’s your Editorial Process?
The most important step is understanding your editorial process and how much control you need to have of content before it goes live.
– for example, consider these 3 points:
1. Do you need 3rd party approvals for images?
2. Do you or your client have to sign-off copy / images / video / layout before content is published?
3. Do you Editors get to work on different weeks or issues and are planning content to go live weeks in advance…
If you answered Yes to any of these, then a single DB shared between your Pre-Live / Staging server and your Live server is not ‘possible’. Why you ask? because a new post has to be published before it can be seen by non-users or 3rd parties who you don’t want to give logins too. (BTW … anything is possible with time, money and skills to customise user roles and access levels).
So back to the WordPress Scalable Solution
DOMAIN A (what your customers & visitors go to ) will need to be pointed to an HTTP Load Balancer.
The Load Balancer will direct the customer traffic to one of several web servers.
These slave servers are kept in LSYNC with a MASTER server.
Ideally, there should be 2 separate DB servers (for load balancing read / write requests and scale). You can expect lots of READ traffic from visitors, but you want to make sure that WRITE traffic from new posts, etc doesn’t interupt with your READ requests.
DOMAIN A can also be pointed to an HTTPS Load Balancer which is configured to
1. only allow traffic from your Office IP address and
2. FORCE SSL connection for Admin / Login.
This is an easy change to the wp-config.php
file.
Here is a diagram of what we built (with some support from Rackspace)
HyperDB
In the end we got HyperDB setup to manage the multiple DB servers and requests. This was also easy as it’s mostly a plugin with a long configuration script.
W3TC W3 Total Cache
We also got HyperDB and W3TC setup .. this took a lot of load of the DB Servers too
The main reason we used W3TC was to off load all the static content to Rackspace. The Content Delivery Network setup in W3TC is also very easy 🙂