Scaling Up or Out Architectural Decisions

Systems and solutions will grow if they are successful.  Therefore, it is essential for us to consider whether this will be handled by scaling up or scaling out.  There are many ways that a solution will need to grow.  There can be limitations based on processing, storage, network, or other areas.  Each of these can grow in the same way or you can mix-and-max your way through these issues.  No matter the approach, it needs to be thought through as part of the architecture.

The first way to scale a system is up.  This essentially keeps everything in place while making it stronger or more powerful.  In the computer world, this can be a bigger storage drive, more memory, or a faster processor.  All of these options help a system respond faster and support more users.  Of course, there is a limit to this growth.  While easier to build, an architecture that is designed to scale up will hit a ceiling at some point.

Scaling out involves replicating systems and using those new ones to provide a service.  You roughly split up the total user base into a bunch of smaller bases that can be served by a smaller solution.  This allows for almost infinite scalability.  The downside is that you have obstacles to overcome to split out the work and make it seamless.  Your users will not often make it easy to splinter them out into groups.  On the other hand, some applications are perfect for scaling out.  This situation is exactly why microservices have their niche.

There is a lot more that factors into which way an application should scale.  Rather than tackle those here, check an article like this one.  Your solution is unique and needs a similar approach to how it scales.  Luckily, growth is a good challenge to face.