Magnolia has built-in clustering capabilities. These come in the form of a pluggable publish-subscribe mechanism that allows to have any number of subscribers for a publisher.
Magnolia by default runs on a multi-instance setup - one authoring and one public instance - where the public instance is subscribed to the authoring instance.
This architecture has a lot of advantages. Two instances provide flexibility, performance and security. It separates concerns, scales well and allows creative solutions for interesting problems. Most of all, it allows to run Magnolia on two (or more) separate servers serving different purposes, namely to author content in a secured environment and to publicly serve the content to site visitors.
Stability of the public instance. Authors have the liberty to do whatever they need to without affecting the public instance. If something they do is so severe that the server needs to be restarted, this is not a problem. This even extends to developers that need to add new templates and other configuration changes that require a restart. All of this can be implemented and tested on the authoring instance without affecting the public instance which is visible by the user community.
The authoring instance needs system resources to facilitate editing content, locating and managing data, and constantly checking permissions. Often, you also output more log information, which costs additional resources.
The public instance is only concerned with generating cached pages and then serving those pages when requested. With this separation, content editors are free to tax this system as much as they like, developers can put in hot fixes required by content editors, and none of this impacts the performance or availability of the public instance.
Commonly, you want the authoring instance to be behind a firewall, and the public instance accessible from the internet. There are mainly two reasons why this setup makes sense - one is to make sure that no one can publish content by directly manipulating the public server, and the second one is to make sure that information is only then available to the public when it should be. A typical example is the publishing of a press release or financial information. Authors can edit the information behind the firewall and only once the publishing date has come, this information is pushed to the public server. So even if - for whatever reason - your public server is compromised, only public information is found on the system. At the same time, since no authors need to access the system directly, you can secure the public server tightly.
Due to this architecture, you can easily run the two instances on two different servers (or more instances on more servers). For instance, one of our customers has the need to publish information to 70 standalone servers for security reasons. Each of these machines needs to be accessible "from within" if their location is cut of from the outside world. In that scenario, one author instance is used to drive 70 public instances - on 70 different servers.
Another example is having 20 different authoring servers publishing to a single public server to present the content -- this is a typical university setup, where each department wants control over its own server, but the university wants a single public access point, preferably using a unified look and feel.