Movable Type System ArchitecturesPosted: January 15, 2009
[Movable Type](http://www.movabletype.org/) is renown in operations circles for a number of its “abilities,” mainly its scalability, availability and reliability. The larger your site gets however, and the more readers you have creating content for you in the form of comments and posts1, the more complex your network architecture may need to become. For many the process of architecting a scalable and high performant Movable Type system can be a daunting task, largely because the process is largely undocumented.
The truth is that there is no one, canonical way to design your Movable Type system or any system for that matter, which is most likely one of the primary reasons contributing to the lack of documentation. So let’s approach this challenge another way. Let’s start with a basic footprint designed for *large* sites powered by Movable Type, and then let the architects add or remove pieces as needed and according to their unique operational requirements and cost constraints.
Below is just such a network, one that serves as the basis for any large scale Movable Type site I typically design:
* **Front-end Web Servers** – these servers serve static files only. If all else fails in your network these will continue to serve content, not to mention your ads, which is the life blood of any large media site.
* **NFS Server** – invest in a single, and very reliable, network storage device, one that your web servers read from, and your publishing daemons write to.
* **Database Server** – have one or two dedicated database servers depending upon whether you want one available for redundancy purposes. These should be beefy machines with a lot of CPU power and a lot of memory. There is a whole other chapter in fine tuning your database, and for that I highly recommend consulting an expert. In my experience however, text doesn’t take up a lot of memory, and with a large enough cache configured for your database, you can practically load up your entire database into memory, resulting in dramatic speed improvements.
* **Comment Servers** – these web servers handle all the write requests from your community and readers including favoriting, commenting, and the like. These can be broken off from your front-end web servers so that they can be scaled independently from the rest. The diagram doesn’t show this, but you may consider having these connected to the NFS server as well and have them handle publishing of your permalink pages synchronously with each comment received. This ensures that when a reader returns to the entry they commented on they will see the comment they just left.
* **Admin Web Servers** – these servers are what your editors access. It is given a dedicated machine so that if you site is under high load you can rest assured that authors and editors can still login and be productive administering the site.
* **Publishing Machines** – these servers are work horses. They handle much of the publishing and virtually all of the non-critical, non-blocking processes on your system, like Action Streams aggregation and most publishing. One simple way to approach this little cluster is with a lot of small cheap machines, or virtual machines that you can easily spin up when your site is under serious load.
Anyways, that’s the basic gist. I would love to learn how others have architected their Movable Type clusters. Let me know in the comments if you don’t mind sharing.
1 – something one is likely to see a lot more of when [Motion](http://www.movabletype.com/motion/) is released.