Fundamental Problems With Micro-Services Architecture

"Organizations design systems that mirror their own communication structure" - Conway's Law

I have worked on both sides of software architecture i.e. monolith as well as micro-services. Over the period of time, I have experienced these problem patterns across micro-services:

Service is simpler, the system becomes complex

Services become easy to maintain, debug and improve. But, the entire system becomes complex especially the communication between different moving parts. With time it becomes difficult to maintain the system as a whole.

State consistency is a nightmare

Maintaining a consistent state of data across services is a primary requirement. Data flow, and data pattern needs proper sync and communication across services. But, it becomes difficult to maintain a consistent state of data across services.

Independence brings too many choices

Languages, tech stacks, and tools will keep on getting introduced across different services. With time it leads to maintenance overhead and increases friction among teams.

Bigger teams are inherent demand

Smaller teams face diminishing returns on productivity. Each service requires a custom development setup, testing, and deployment pipelines. It impacts the speed of development and with time needs more resources.

Communication congestion becomes the norm

Granular services need more inter-service communication, especially from a state consistency perspective. It results in longer request-response times increasing latency. With time, as the number of services increases, this becomes a difficult challenge. Ironically, this holds true for teams also, as communication friction between teams tends to increase.

Hence, from a problems perspective you are very likely to face above challenges. To make a decision about monolith vs microservices architecture give a good thought to the above problems and how you'll tackle them.

Useful Tip: microservices are more an organizational pattern than a software pattern.