Three different system architectures

1. Monolithic System with one data source

In a monolithic architecture, a single application exists on the server side, containing the application's entire API.

An advantage of this architectural approach is the application's low complexity.

Disadvantages include inefficient scalability and the fact that the entire application must be shut down to install a new version. Under high server load, an additional monolith must be started to handle requests from the many clients.

A monolith is generally the first choice when launching new software. This approach is preferable when the expected server load is not yet clear, as it avoids unnecessary complexity.

2. Distributed System with one shared data source

In a distributed architecture with a shared database, multiple applications exist on the server side that collectively constitute the application's entire API.

An advantage of this architectural variant is the improved scalability of the server application. For instance, in the case of an online store, there might be three separate applications handling products, customers, and orders. Product data is typically maintained by only a few employees; consequently, the product API sees significantly less traffic than, say, the order API in a busy store. During peak times, only additional instances of the order module need to be launched, while the product module continues to run with just a single instance. Another advantage is that the entire application landscape does not need to be shut down. If the product module requires an update, for example, customers can still place orders—a clear benefit for the store's revenue.

A disadvantage of this architecture is the increased complexity on the server side. Furthermore, despite distributing the API across multiple modules, the shared database can become a bottleneck, as it receives requests from all the server modules' APIs. However, the data remains synchronized thanks to the database's consistency mechanisms.

This architecture makes sense when the load varies significantly across the different module APIs. This can justify the effort of managing multiple applications, as opposed to using a monolithic architecture.

3. Distributed System with synchronized data sources

The distributed architecture with multiple databases, also known as classic microservice architecture, has the highest complexity.

The advantage of this architecture variant is the high scalability of the server landscape. The additional distribution of the database model can eliminate the potential bottleneck of the shared database architecture.

The disadvantage of this architecture is the introduction of asynchrony between the databases. The data is only eventually consistent at any given time. The consistency between the databases is only established with a time delay via a so-called message broker. This can result in clients receiving conflicting information. For example, there could be 15 reviews for a product on a shop website, even though the headline says 14 reviews, because the 15th review was just written by me. This asynchrony can be unpleasant, but tolerable. However, it can also be unacceptable when it comes to sensor data in a technical device, for example, where the sensor value accurate to the second is required for real-time control. In this case, synchrony must be enforced. This then comes at the expense of the availability of the server landscape.

The microservice architecture should only be used if the framework conditions make it absolutely necessary due to an extremely large number of API clients.

3.1 Module Coupling

(1)	(2)	(3)	(4)	(5)	(6)	(7)	(8)	(9)	(10)	Module
6.00	2.00	0.00	0.00	1.00	2.00	0.00	1.00	1.00	0.00	(1) AdresseService
2.00	6.00	2.00	1.00	3.00	1.00	2.00	1.00	1.00	2.00	(2) LokaleTafelService
0.00	4.00	5.00	0.00	0.00	0.00	0.00	0.00	0.00	2.00	(3) MitarbeiterService
0.00	2.00	0.00	4.00	1.00	0.00	0.00	0.00	0.00	0.00	(4) TraegervereinService
1.00	4.00	0.00	2.00	4.00	0.00	0.00	0.00	0.00	0.00	(5) BundesverbandService
1.00	1.00	0.00	0.00	0.00	3.00	0.00	0.00	1.00	0.00	(6) SpendeService
0.00	3.00	0.00	0.00	0.00	0.00	3.00	1.00	0.00	0.00	(7) AusgabeTerminService
1.00	1.00	0.00	0.00	0.00	0.00	1.00	3.00	1.00	1.00	(8) StandortService
1.00	1.00	0.00	0.00	0.00	1.00	0.00	1.00	2.00	1.00	(9) LagerService
0.00	2.00	1.00	0.00	0.00	0.00	0.00	1.00	1.00	2.00	(10) EhrenamtlicherService

3.2 Normalized Module Coupling

(1)	(2)	(3)	(4)	(5)	(6)	(7)	(8)	(9)	(10)	Module
0.46	0.15	0.00	0.00	0.08	0.15	0.00	0.08	0.08	0.00	(1) AdresseService
0.10	0.29	0.10	0.05	0.14	0.05	0.10	0.05	0.05	0.10	(2) LokaleTafelService
0.00	0.36	0.45	0.00	0.00	0.00	0.00	0.00	0.00	0.18	(3) MitarbeiterService
0.00	0.29	0.00	0.57	0.14	0.00	0.00	0.00	0.00	0.00	(4) TraegervereinService
0.09	0.36	0.00	0.18	0.36	0.00	0.00	0.00	0.00	0.00	(5) BundesverbandService
0.17	0.17	0.00	0.00	0.00	0.50	0.00	0.00	0.17	0.00	(6) SpendeService
0.00	0.43	0.00	0.00	0.00	0.00	0.43	0.14	0.00	0.00	(7) AusgabeTerminService
0.12	0.12	0.00	0.00	0.00	0.00	0.12	0.37	0.12	0.12	(8) StandortService
0.14	0.14	0.00	0.00	0.00	0.14	0.00	0.14	0.29	0.14	(9) LagerService
0.00	0.29	0.14	0.00	0.00	0.00	0.00	0.14	0.14	0.29	(10) EhrenamtlicherService

3.3 Coupling Analysis

Modules	10
Global Entities	38
Min. Entities per Module	2
Max. Entities per Module	6
Average Entities per Module	3.80
Local-only Entities	6
Distributed Entities	32
Transfer Entities	60
Inter-Process-Transfers	40
Max-Possible-Process-Transfers	90
Transfer Effort	44.4
Isolation Quality	-57.9