Scale cube and micro-services
The model defines three ways to scale an application: X, Y, and Z.

X-axis scaling
X-axis scaling is a commonly to scale an application. You simple run multiple instances of the application behind a load balancer.

The load balancer distributes requests amongst the N identical instances of the application.
Z-axis scaling
Z-axis scaling also runs multiple instances of the application. However, unlike X-axis scaling, each server is responsible for only a subset of the data. The router in front of the instances uses an attribute of request to route it to the appropriate instance.

The router uses the x attribute of the request to decide select one of the N identical instances of the application. A commonly used attribute is the userId. Different users are routed to different instances of the application.
Y-axis scaling
X and Z-axis scaling improve the application's capacity and availability. Neither approach, however, solves the problem of increasing development and application complexity. To solve those problems we need to apply Y-axis scaling a.k.a. functional decomposition. Y-axis scaling splits a monolithic application into a set of services.

A service, is a mini-application that implements a set of related functionality such as order management, customer management, etc. A service is called using X-axis and Z-axis when necessary. “For example, the Order Management service is deployed as a set of load balanced service instances.”
This is my high-level definition of micro-services: an architectural style that functionally decomposes an application into a set of services. Note that this definition does not say anything about size. Instead, what matters is that each service has a focussed, cohesive set of responsibilities.
Micro-services as a form of modularity
The micro-service architecture uses services as the unit of modularity. A service has an impermeable boundary that is difficult to violate. As a result, the modularity of the application is much easier to preserve over time. There are other benefits of the micro-service architecture including the ability to deploy and scale services independently.
Each service has its own database
A key characteristic of the micro-service architecture is that the services are loosely coupled. One way this loose coupling is achieved is by each service having it's own datastore.
Now that we have defined the micro-service architecture and described some of its essential characteristics, lets look how this applies to the FTGO application.
Benefits of micro-services
- First, each service is relatively small. The code is easier for a developer to understand.
- Second, each service can be deployed independently of other services.
-
Third, each service can be scaled independently of other services using X-axis cloning and Z-axis portioning.
Drawbacks of micro-services
-
One challenge with using the micro-service architecture is that there isn’t a concrete, well-defined algorithm for decomposing a system into services.
-
Another challenge with using the microservice architecture is that developers must deal with the additional complexity of creating a distributed system. Developers must use an inter-process communication mechanism.
- Implementing the use cases that span multiple services requires the use of unfamiliar techniques.
- IDEs and other development tools are focused on building monolithic applications and don’t provide explicit support for developing distributed applications.
- Writing automated tests that involve multiple services is challenging.
- The micro-service architecture also introduces significant operational complexity.
- There are many more moving parts — multiple instances of different types of service — that must be managed in production.
- Also, developing features that span multiple services requires careful coordination between the various development teams.
-
Another challenge with using the micro-service architecture is deciding at what point during the lifecycle of the application you should use this architecture.
- Using an elaborate, distributed architecture will slow down development.
Because of these issues, adopting a micro-service architecture should not be undertaken lightly. However, for complex applications, such as a consumer-facing web application or SaaS application, it is usually the right choice.
Micro-service architecture pattern language
What is a pattern?
A commonly used pattern structure includes three especially valuable sections: forces, resulting context, and related patterns.
Force
Code written in a reactive style has better performance than synchronous code, yet is often more difficult to understand.
Resulting Context
The resulting context section describes the consequences of applying the pattern. It consists of three parts:
- benefits — the benefits of the pattern including the forces that have been resolved
- drawbacks — the drawbacks of the pattern including the unresolved forces
- issues — the new problems that have been introduced by applying the pattern.
Related Patterns
The related patterns section describes the relationship between this pattern and other patterns. There are three types of relationships between patterns
- Predecessor — a predecessor pattern is a pattern that motivates the need for this pattern.
- Successor — a pattern that solves an issue that is introduced by this pattern.
- For example, if you apply the Micro-service successor patterns including service discovery patterns and the Circuit Breaker pattern.
- Alternative — a pattern that provides an alternative solution to this pattern.