The service-based architecture is one of the most commonly used software architecture styles. It is a hybrid of different microservices architecture styles, and is highly flexible. It is a popular choice among distributed architectures due to its simplicity.
The basic topology of the service-based architecture is like a distributed version of the monolithic layered architecture, plus a separately deployed user interface and monolithic database. The services within this architecture are known as domain services, which are each separately deployed, typically in the same manner as any monolithic application.
Key Properties
Scaling Constraint
Because of the fact that there is a single monolithic database, the number of services within the service-based architecture cannot be too large. It usually ranges between 4 and 12 services.
In most cases, there is only a single instance of each service due to the scaling constraint, but it is possible to include multiple instances of the same service.
Service Access Protocol
Services are usually accessed from the user interface through a remote access protocol. REST is the most common choice, but messaging, remote procedure call (RPC), and SOAP can also be used.
Centralized vs. Non-Centralized Database
The service-based architecture typically uses a centralized database. Because of the limited number of services, database connections are usually not a bottleneck.
However, database changes can be an issue. This is because there is a single shared library that contains all of the database table schemas, and if any changes are made to the schemas, it must be redeployed to every service.
The solution is to partition the database by domain or have separate domain-scoped databases altogether, so that services in the same domain would share a database. In some cases, there could even be a separate database for each service. However, the tradeoff is that we must make sure that only the services that are connected to a certain database actually need to access its data, otherwise we end up with more inter-service communication and duplication of data.
Centralized vs. Non-Centralized User Interface
Although the most typical case of this architecture style is to have a single monolithic user interface, there are variants to this style where multiple user interfaces can exist. There could be domain-based user interface, where each user interface serves multiple services in the same domain, or service-based user interface, where each user interface serves a single service.
Service Design
As mentioned above, the service-based architecture is like a distributed version of the layered architecture. This is because each service can be thought of as a monolithic layered application. A typical service consists of the following layers:
- API Layer: provides access to the service for the user interface.
- Business Logic Layer: the core layer that executes the business logic of the service.
- Persistence Layer: executes queries and persists data to the database.
Trade-Offs
Advantages
- This architecture style allows fast changes due to separately deployed services.
- The limited scope of services enables easy testing and frequent deployments.
- Fault tolerance and reliability are relatively high, because services are usually self-contained, so if one service goes down, it does not impact the other services.
- The simplicity and overall cost of this architecture style is in between monolithic architectures and other distributed architectures. So if a distributed architecture is needed but simplicity is desired, then this would be a great choice.
Disadvantages
- The scalability is limited, especially when there is a single monolithic user interface and/or database. It is difficult to scale up certain services that have high processing demand relative to other services.
