Contemplating how to scale your website is not often a paramount concern in the early days when the focus is on time to market and core functionality. Growth over time will eventually force you to architect a solution to get ahead of the growth and deliver the availability and scalability the business demands. The AKF Scale Cube is one way to frame the scalability challenge.
The AKF Scale Cube has three axes by which a website can be scaled. X axis, or horizontal duplication, is a common first choice. Duplicating web and app servers into load balanced pools is a best practice that provides the ability to conduct maintenance or roll code without taking the site down as well as scalability if the pools are N+1 or even N+2.
The Y axis is a service split - decomposing a monolithic code base into smaller services than can run independently. The Y axis also allows you to scale your technology team - teams focus on the services for which they are responsible and no longer need complete domain expertise. Y axis does require a lot of development work though, competing for resources the business wants to use for new features.
You can read more about the Scale Cube and the X and Y axes here.
The third axis is Z, a lookup oriented split. A common choice is geographic location or customer identity. A Z axis split takes a monolithic stack and slices it into N smaller stacks, using fewer or smaller servers and working with 1/Nth of the data.
A case can be made that a Z axis split is your best option when X axis is losing effectiveness and infrastructure costs are becoming unsustainable. Consider this situation; you have already implemented X axis split by deploying load balanced pools of web and app servers. You've gone a step further by deploying read-only DB replicas to handle reporting workloads, preserving compute power for the write DB. It's not enough though, your production DB is wheezing after going up one flight of stairs.
The business intentionally took on technical debt in the form of stored procedures for business logic early on to improve time to market. Development resources are now slowly removing those and writing the business logic in the app tier. New features are still needed so there are no resources to begin on the development work needed for a Y axis split.
X axis is running out of steam and increasing costs and you do not have resources to work on a Y axis split in the near term. Z axis can save the day and provide some breathing room. Z axis does not take as much development work as Y does and the X axis infrastructure work your team has already done will be similar to building smaller Z axis stacks. Your team develops cookie cutter stacks via automation and scripting that handle 2,500 customers well. You start a new stack when the previous one reaches 2,000 customers to leave some depth of data growth. These smaller stacks reduce your growth costs as compared to Z axis alone. The business has time to complete the stored procedure removal before turning towards Y axis service splits all the while delivering on the feature roadmap. You keep your job.