Note: macroservices and miniservices architectures are implemented in the same way. The particularity of macroservices is that they run in the same container (like Apache Tomcat).
In GeneXus, a macroservices / miniservices system can be implemented with only one Knowledge Base that should be organized with Modules.
Unlike monolithic systems, in these cases, a system is distributed in several webapps. That is, there are several subsystems (several business logics). This provides flexibility.
There is a single database with which all the subsystems work.
ACID (atomicity, consistency, isolation, durability) features are present in the data and ensure that it is persisted correctly. All operations are performed on the same database; therefore, regardless of the complexity of what needs to be addressed, the results will be accurate because the system will be highly cohesive.
The concept of Extended Table can be used, there is a good performance when making joins, etc.
All screens will have the same style and will use the same Design System.
Each webapp is independently deployed. This is a benefit because, for example, if the mobile services webapp has to be deployed, this does not affect the back office services webapp or other webapps.
Having a single database implies that any problems that occur in it will affect all the webapps.
When the database is reorganized, it will be necessary to ensure that all the webapps continue working (when the database is reorganized, if only one webapp is moved and any change affects another webapp that was not updated, errors will occur).
Scalability will depend on the database.
Integration between webapps will be needed (if from one webapp you need to call an object that is in another webapp, the solution is to use a Dynamic link to solve it).
The Coronavirus UY application was a monolithic application when it was first released. In its second release, the application was moved to a miniservices architecture.
The single KB with N modules where all developers work was kept. To transform the architecture to miniservices, separate Deployment Units were defined (one Deployment Unit for mobile services, one Deployment Unit for batch processes, one for the back office, and another for the front office). This made deployment much easier. To update part of a given webapp, only that Deployment Unit has to be distributed again.
As in these kinds of systems, there are several webapps (to be able to update a webapp without having to update the others) and they all work on the same database, the changes to be done in the database must be backward compatible. This means that reorganizations must be done with caution avoiding changes that are useful for a webapp but damage other webapps. A feature that can be helpful is to turn information notifications shown in the Impact Analysis Report into errors to avoid certain changes. Read more in Warnings treated as errors property.