Quantitative scaling

• How well a web service handles substantial volumes depends on a triangle of three factors: capacity, velocity, and effectivity.

• Capacity

  The capacity of a train is the number of available seats. A longer train with more seats can transport more passengers towards their destinations in a single journey.

  Likewise, in the realm of software projects, the servers running the software make up the capacity. Projects experiencing their first scalability issues are sometimes helped by migrating to a larger, single server. More mature projects require their software to be split into several services along sensible lines.

  Once split, it is possible to fine-tune capacity per service. Ultimately, autoscaling can be established, where capacity is dynamically adjusted to meet the ever-changing demand at any given point in time: scaling up to ensure availability during peak demand periods; scaling down during off-peak periods to minimise costs.

• Velocity

  The faster a train travels, the more trips it can make. The train can thus transport more passengers in a day.

  Performance bottlenecks ‒ segments which require way more computational power than their surroundings ‒ always exist in software. One optimises a bottleneck by replacing the implementation for a faster one which functions the same.

  The degree to which a bottleneck can be optimised is highly variable. Certain bottlenecks only allow for a modest 2× or 10× optimisation, and those are usually not worth the effort. Conversely, others present more lucrative opportunities and allow for 100× or 1000× optimisations, making them more fruitful.

• Effectivity

  A train crossing a bridge across a lake reaches the other side quicker than one which follows the alternative lengthier path around the lake.

  In the face of scaling issues, the natural inclination is to focus solely on capacity and velocity. Nevertheless, it is worthwhile to contemplate whether there are ways to accomplish the same outcome with less effort. Less is more.

  Doing less comes in many forms: introducing cache layers; prebuilding document chunks which are less volatile in nature; inserting debounce gates; strategically moving related resources in close proximity to one another; et cetera.

• No silver bullet

  When it comes to quantitative scaling of web services, there is no universally applicable or standardised solution that can fit every scenario. Each project carries its own needs and peculiarities.

  The strategy we have found most productive over the years is building projects from the ground up with quantitative scaling in mind, while deferring the development of scaling features until they become necessary.

  Nullhouse is an agency specialised in both qualitative and quantitative scaling. We can help you identify the most advantageous path forward for your project. Whether you are looking to optimise an existing web service or develop a new one, we can provide expert guidance and support to help ensure that scale is not an issue.

  Contact us