Scalability Choices in Software Architecture, I of III

Someone asked about software scalability, so I decided to write a blog about it, comparing different choices.

Horizontal Scaling vs Vertical Scaling

Horizontal scaling (or scaling out) is scaling by means of adding low-cost commodity systems (nodes).

Vertical scaling (or scaling up) is scaling by means of adding resources (CPUs, memories) to a single system.

Vertical scaling has advantages in terms of programming model and manageability, but could be more expensive, and cannot scale indefinitely. Horizontal scaling is the preferred choice for scalability.

At Oracle, where I worked, vertical scaling seemed to be the norm, particularly after Oracle purchased Sun and got into the hardware and systems business. At Opera, which is my new employer, we are focussed on horizontal scaling.

Horizontal Partitioning vs Vertical Partitioning

Horizontal partitioning (or sharding) splits data of a certain type by some criteria, and stores and manages them in different instances. For example, data for customers in the US stored and managed in US-based instance, and data for customers in the UK stored and managed in UK-based instance.

Vertical partitioning splits data by business function and stores and manages them in different instances. For example, customer data stored and managed in one instance and product data stored and managed in another instance.

Both horizontal and vertical partitioning are important tools for scalability and the choice depends on the task at hand. For complex systems, vertical partitioning would modularize the systems and each could be independently managed by separate teams, so that is an added bonus.

For really large volumes of data, horizontal partitioning should be considered. Personally, I have never been involved with such large volumes of data, but I can think of a number of challenging situations that may arise if the data relationships are complex.

Note that the above comments are not related to database partitioning. Conceptually similar, but in case of database partitioning, different tables are used in the same instance for partitioning.