Today I stumped upon this discussion on Reddit about microservice. I really love the term “Cthulhu Architecture” one user used to describe a monolith which falsely presents itself as a microservice. Cthulhu, which is a monster which spreads and wraps it tentacles around everything, which are devotedly followed by cultists, and touching anywhere of the monster is the job of a single maddening developer who the whole company knows and fears. Quite a fitting description of a monolith disguiding itself as a microservice.

This types of architecture, in my understanding, are bornt when the company tries to sell the keyword ‘microservice’ without understanding the heart of microservice: to decouple teams or, in Conway’s law, reducing communication between irrelevant teams within an organization. Communication about feature implementation, about service and API versioning, about shared data and migrations, about detached solutions for CI/CD. The best microservice is adapted properly when all teams within an organization can solve the problem together with minimum communication between them. If the communication needs to happen constantly and frequently about everything, throughout the project, then the codebase is more or less ‘cthulhu’-like.

There are also other reasons for going microservice, like scaling or separation of technology stacks, but if the company cannot resolve the communication decoupling problem, then no matter how they splits the code base, there would be one developer who, in the end, holds the business knowledge of the whole system in order to answer every questions about design decisions and helps to debug anything related. This is simply a result of communication failure - either there should be someone who knows all or everyone would know not enough to maintain the project, due to low or no decoupling.