If you notice a lot of the issues listed below in your project/system/application probably your project is hell:

• you do not know what the responsibility of a given microservice is – what it really does and why
• you don’t know what the interface/contract is
• new functions/story has to be implemented in several services
• you do not know where the source of truth is
• you solve one bug and create others
• to find a problem, you have to analyze processes step by step
• broad knowledge is needed for bug fixing and coding effectively new functions
• a large number of communications in the system between microservices
• application is working slowly under load
• instability of one service causes instability in whole system or even freezes the business processes
• deploy of new version = deploy all services
• deployment of one service is risky
• no contract tests
• mainly e2e tests
• big domain/dto objects
• the same model/class/data are used in many services
• many if/switch statements to distinguish different processes
• business logic of one requirement is implemented in many services
• hard to create and maintain documentation
• many teams change the code at the same service(even classes) at the same time
• dependence on other teams
• high complexity

If you encounter many of these problems in your project, you work with a distributed monolith system. It is characterized by an excessive amount of dependencies/high coupling and high complexity. Causes a lot of problems and the consequences are very negative. Clients complain that the system is working slowly, is unstable, and has bugs. Business complains that providing new functions takes more time than expected. Testers complain because system is unstable and has many bugs. Developers complain because the complexity is very high. In summary, no one is really happy.