Scaling Effects

Scaling effect

In Biology, the square-cube law explains why we’ll never see elephant-sized spiders. The bug’s weight scales with volume, so it goes as O($n^{3}$). The strength of the leg scales with the area of the cross section, so it goes as O($n^{2}$). If we make the critter 10 times as large, that makes the strength-to-weight ratio one-tenth of the small version, and the legs just can’t hold it up. We run into such scaling effects all the time. Anytime we have a many-to-one or many-to-few relationship, we can be hit by scaling effects when one side increases. For instance, a database server that holds up just fine when ten machines call it might crash miserably when we add the next 50 machines.

Application in development, QA, and production

In the development environment, every application runs on one machine. In QA, pretty much every application looks like one or two machines. When we get to production, though, some applications are really, really small, and some are medium, large, or humongous. Because the development and test environments rarely replicate production sizing, it can be hard to see where scaling effects will bite.

Point-to-point communication

One of the worst places that scaling effects will bite is with point-to-point communication. Point-to-point communication between machines probably works just fine when only one or two instances are communicating, as in the following figure.