The scalability of content management systems is a topic not often initially evaluated in-depth, as it is very technical and therefore invisible – at least until the first service interruption. Especially in unexpected situations of popularity or crisis, when smooth communication with customers and employees is vital, the additional load of the system could potentially increase so much that it breaks down – comparable to a DDoS attack.
This might be a painful lesson to learn because scalability is more than just asking “how many visitors and assets can our CMS and our servers handle”? In fact, the load patterns of web applications are subject to great fluctuation. Therefore, it is not surprising that the scalability of CMSs is rarely questioned in detail, hardly tested and even less frequently measured. In many cases scalability remains an untested assumption.
With legacy, on-premise CMSs, the most important parameters of scalability are predefined and static: The CPU and I/O throughput capacity on the CMS servers, databases and load-balancers, combined with the complexity of the customizations, defines the time it takes to render a single page. Even rare changes of these parameters show the necessity of either modifying the scope of the contract or modernizing and expanding hardware, not to mention the involvement of IT specialists to adjust the software. This takes time.
Also, the capacity of this legacy environment has its limits. Every sudden peak in web traffic affects performance and availability. The traditional approach also needs a much longer reaction time for scaling. That explains why so many brands face service overload problems during moments of great success, or – even worse – emergency.
In addition to traffic growing unpredictably, so does the content volume. As a rule of thumb, content volume follows Moore’s Law and doubles every 18 months. If there is a requirement to archive the content history, then this increases even more. In addition, content is becoming increasingly personalized. This means that the CMS must be designed to handle a multiple of the initial content. Unfortunately, nobody initially knows exactly how much will be needed in practice. The only way to handle this unpredictability is to achieve linear scalability or even better.
Also, the ability to dynamically adapt commercial conditions in a pay-per-use model is one of the factors that scale the business plan. Why overpay for a service you do not use, or wait hours for the support department’s response to a sudden traffic peak?