Not so long ago, about 5 years ago, there was a very popular discussion of the so-called transition from a monolithic architecture to microservices.
          The so-called docker containers, which were considered almost a panacea for everything, and tried to use them wherever possible.
            This is of course not exactly microservices, but one of the means of implementing microservices.
           A certain amount of time has passed and we will try, so to speak, to sum up the existing information and make an analysis of these approaches.
First definition of monolith and microservices.

          Monolithic architecture is a traditional software model, which is a single module that works autonomously and independently of other applications. A monolith is often referred to as something large and unwieldy, and this describes well a monolithic architecture for software design. A monolithic architecture is a separate sufficiently large computing network with a single code base in which all business tasks are combined. To make changes to such an application, you need to update the entire stack through the code base, as well as create and deploy an updated version of the interface that is on the service side.

Simple deployment. Using a single executable file or directory simplifies deployment.
Development. An application is easier to develop when it is built using a single codebase.
Performance. In a centralized codebase and repository, one API can often perform the same function that multiple APIs perform when working with microservices.
Simplified testing. A monolithic application is a single centralized unit, end-to-end testing can be done faster than using a distributed application.

Convenient debugging. All code is in one place, making it easier to run queries and find issues.

Microservices provide the following benefits.
Flexibility. Promote agile practices to small teams that deploy regularly.
Flexible scaling. When a microservice reaches its load limit, you can quickly deploy new instances of that service to a companion cluster and reduce the load. Now we are working with multiple holders and stateless, and the clients are spread across different instances. With this approach, we can support much larger instances.

Continuous Deployment. We now have regular and accelerated release cycles. If earlier we released updates once a week, now we can do it about two or three times a day.
Ease of maintenance and testing. Teams will be able to experiment with new features and revert to a previous version if something doesn`t work. This will greatly simplify code updates and speed up the release of new features to the market. In addition, it is easy to find and fix errors and bugs in individual services.
Independent deployment. Microservices are separate modules, so you can easily and quickly deploy individual functions independently with them.

Technology flexibility. With a microservices architecture, teams can choose tools based on their preferences.
High reliability. By deploying changes to a specific service, you don`t have to worry about the whole application going down.

Happy teams. Atlassian teams working with microservices have better feedback on their work due to autonomy and the ability to build and deploy applications on their own without having to wait weeks for a pull request to be approved.

Flaws. Growth of the development process. Microservices add complexity compared to a monolithic architecture, as more and more services are spawned in different places, created by multiple teams. If sprawl is not properly controlled, it slows down development and reduces operational efficiency.
Exponential growth in infrastructure spending. Each new microservice can have its own cost for a test suite, deployment instructions, hosting infrastructure, monitoring tools, etc.

Debugging issues. Each microservice has its own set of logs, which makes debugging more difficult. In addition, additional difficulties may arise when a single business process is running on multiple machines.
Lack of standardization. Without a common platform, a situation can arise in which the list of languages, logging standards, and monitoring tools grows.

Lack of clarity in ownership issues. With each appearance of new services, the number of teams working on them increases. And it becomes more difficult to determine what services the team can use and who should be contacted for support.

        So proper microservice boundaries are the foundation of a healthy microservice architecture.

       Also, to minimize errors when defining boundaries, you first need to think through them. Therefore, the Monolith First approach is justified, when the system is first developed in the traditional paradigm, and when established areas appear, they are separated into microservices.

        Now let`s try to consider a specific example of building a microservice.
The man decided to remake his project, it was originally written on a monolith and rewrite everything on a monolith.            Now let`s talk about this experience and what this project was like.
It was a home project (although rather its prototype), which was decided to be rewritten for microservices. The project was an attempt to make an educational Java game. That is, the player has a field, on this field he can control some unit using a code. Writes code, sends it to the server, where it is executed and returns the result, which is displayed to the user.

        All this was implemented in the form of a prototype - there were users, one lesson and one task for it, the ability to send code that was compiled and executed. Technologies - Spring Boot, Spring Data, Gradle.
       In short: instead of one large application, we have many small ones that have a very narrow scope and interact with each other.
        The first step is to break the logic into a number of microservices:
user-service: service with users (create, view, possibly authorize);
lesson-service: service with lessons (create, view lessons and tasks);
result-service: response service (sending completed tasks, storing results);
task-executor-service: code execution service (compiling and executing tasks).

       At this stage, the idea appears that the frontend and individual microservices need to somehow communicate with all this. It seems inconvenient if everyone knows each other`s API and addresses.
         Therefore, another service appears - gateway-service - a common entry point.
         The project outline will look like this:

           Previously, before the breakdown into microservices, authorization was standard - by login and password.
Now the task is expanding, and each of the services must understand whether the user who made the request to the service is authorized. And this despite the fact that requests come not only directly from the user, but also from other services.

         The idea is simple - instead of cookies, on which authorization is usually based, the authorizing service will issue a certain token, which includes user data, time of issuance, and other information you need. Then, for any access to services, the client must pass this token in the header (or something else, as it is more convenient). Each service is able to decrypt what kind of user it is, and he does not need to climb into the database and all that.

     The advantage of microservices is the freedom to choose technologies independently of other parts of the application.
       You can use a new type of database for each. But we have three MySQL databases instead of one, for user-service, lesson-service and answer-service. A task-executor-service must store some task code into which custom code is inserted to execute the task. It will be stored without a database, just as files.
      At the time of dividing the schema into three bases, I had a question - what about foreign keys, data integrity at the database level. As it turned out, nothing. More precisely - everything is at the level of business logic.

https://www.youtube.com/watch?v=EYqClvJ3yp4