https://www.puncsky.com/notes/41-how-to-scale-a-web-service
https://akfpartners.com/growth-blog/akf-scale-cube-ze-case-for-z-axis
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.
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.
https://akfpartners.com/growth-blog/scale-cube
Scaling Solutions with the Z Axis of the Scale Cube
Whereas the Y axis addresses the splitting of dissimilar things (often along noun or verb boundaries), the Z-axis addresses segmentation of “similar” things. Examples may include splitting customers along an unbiased modulus of customer_id, or along a somewhat biased (but beneficial for response time) geographic boundary. Product catalogs may be split by SKU, and content may be split by content_id. Z-axis scaling, like all of the axes, improves the solution’s transactional scalability and if fault isolated it’s availability. Because the software deployed to servers is essentially the same in each Z axis shard (but the data is distinct) there is no increase in organizational scalability. Cache hit rates often go up with smaller data sets, and operational costs generally go down as commodity servers or smaller IaaS instances can be used.
AKF’s Most Commonly Adopted Architectural Principles
N + 1 Design
At least one additional instance of that system in the event of failure.
Design for Rollback
Design to Be Disabled
This will give you additional time to “fix forward” or ensure that your system doesn’t go down as a result of a bug that introduces strange, out-of-bounds demand characteristics to the system.
Design to Be Monitored
identifying services that are alive or dead, examining or polling log files, collecting system-related data over time, and evaluating end-user response times.
applications and systems are designed from the ground up to be if not self-healing, then at least self-diagnosing.
Significant standard deviations from the mean could be “alerted” for future or immediate action depending on the value. This approach leverages a control chart from statistical process control.
Rates of errors, the response time from other services
Design for Multiple Live Sites
Ensuring that the business environment in which you operate, including contracts, partners, and facilities, is also scalable.
Use Mature Technologies
Asynchronous Design
Stateless Systems
consider storing state with the end user rather than within your system. If that is not possible, consider a centralized state caching mechanism that keeps state data off of the application servers and allows for its distribution across multiple servers.
Scale Out, Not Up
Design for at Least Two Axes of Scale
Buy When Non-Core
Use Commodity Hardware
Build Small, Release Small, Fail Fast
Isolate Faults
Segment your product such that the failure of a service or subservice does not affect multiple other services. Alternatively, segment your customers such that failures for some customers do not affect failures for your customer base in its entirety.
Automation over People
SMART guidelines: Specific, Measurable, Achievable, Realistic, Testable
AKF’s Most Commonly Adopted Architectural Principles
- Horizontal Duplication and Cloning (X-Axis ). Having a farm of identical and preferably stateless instances behind a load balancer or reverse proxy. Therefore, every request can be served by any of those hosts and there will be no single point of failure.
- Functional Decomposition and Segmentation - Microservices (Y-Axis). e.g. auth service, user profile service, photo service, etc
- Horizontal Data Partitioning - Shards (Z-Axis). Replicate the whole stack to different “pods”. Each pod can target a specific large group of users. For example, Uber had China and US data centers. Each datacenter might have different “pods” for different regions.
https://akfpartners.com/growth-blog/akf-scale-cube-ze-case-for-z-axis
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.
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.
https://akfpartners.com/growth-blog/scale-cube
Scaling Solutions with the Z Axis of the Scale Cube
Whereas the Y axis addresses the splitting of dissimilar things (often along noun or verb boundaries), the Z-axis addresses segmentation of “similar” things. Examples may include splitting customers along an unbiased modulus of customer_id, or along a somewhat biased (but beneficial for response time) geographic boundary. Product catalogs may be split by SKU, and content may be split by content_id. Z-axis scaling, like all of the axes, improves the solution’s transactional scalability and if fault isolated it’s availability. Because the software deployed to servers is essentially the same in each Z axis shard (but the data is distinct) there is no increase in organizational scalability. Cache hit rates often go up with smaller data sets, and operational costs generally go down as commodity servers or smaller IaaS instances can be used.
AKF’s Most Commonly Adopted Architectural Principles
N + 1 Design
At least one additional instance of that system in the event of failure.
Design for Rollback
Design to Be Disabled
This will give you additional time to “fix forward” or ensure that your system doesn’t go down as a result of a bug that introduces strange, out-of-bounds demand characteristics to the system.
Design to Be Monitored
identifying services that are alive or dead, examining or polling log files, collecting system-related data over time, and evaluating end-user response times.
applications and systems are designed from the ground up to be if not self-healing, then at least self-diagnosing.
Significant standard deviations from the mean could be “alerted” for future or immediate action depending on the value. This approach leverages a control chart from statistical process control.
Rates of errors, the response time from other services
Design for Multiple Live Sites
Ensuring that the business environment in which you operate, including contracts, partners, and facilities, is also scalable.
Use Mature Technologies
Asynchronous Design
Stateless Systems
consider storing state with the end user rather than within your system. If that is not possible, consider a centralized state caching mechanism that keeps state data off of the application servers and allows for its distribution across multiple servers.
Scale Out, Not Up
Design for at Least Two Axes of Scale
Buy When Non-Core
Use Commodity Hardware
Build Small, Release Small, Fail Fast
Isolate Faults
Segment your product such that the failure of a service or subservice does not affect multiple other services. Alternatively, segment your customers such that failures for some customers do not affect failures for your customer base in its entirety.
Automation over People
SMART guidelines: Specific, Measurable, Achievable, Realistic, Testable
AKF’s Most Commonly Adopted Architectural Principles
