Decomposed versus “monolithic” microservices

Question

Microservices are normally designed according domains. These can become quite large even for smaller companies. But what about very big companies with a lot of smaller and bigger differences between their service offerings, e.g., due to legal requirements, local characteristics, size, etc.?

I see two alternatives:

• First alternative: decompose microservices by subdomain (or bounded context). The more general parts use more specialized microservices (subdomains), like layers of onions (see for example https://microservices.io/patterns/decomposition/decompose-by-business-capability.html or https://medium.com/design-microservices-architecture-with-patterns/decomposition-of-microservices-architecture-c8e8cec453e)
• Second alternative: a big "micro"service, so to say a monolitic microservice, which covers all eventualities.

My questions are:

• If the first alternative is preferable:
  • in an event-based environment (e.g. Kafka), should these services integrate each other asynchronously (Kafka) or synchronously (e.g. REST) for queries, commands and updates?
  • with a lot of subdomains and subsubdomains, a lot of process spaces have to be left and entered. Wouldn't this be a load or performance overkill?
  • it seems difficult to decide which logic belongs to the more general services and which logic to the more specialized ones. Which service owns which data? Wouldn't this require a lot of coordination? Are there best practices available?
• If the second alternative is preferable: this alternative sounds like a monolith, which comes along in the robes of a microservice. But what is big? Despite its size, it seems but be much easier to implement a big service in teams than decomposed services (e.g. teams implement general and special requirements)?
• Are there additional / better alternatives available?
• It could be great to refer to a blog or some literature with details regarding the questions above.

Answer 1

It depends™.

To give an example of monoliths: Facebook uses a monolith and if I recall correctly if they had to build a deployment that used torrents to decentralice the download as it was +1GB. This is tens (or +100?) teams working on the same application. A common reason to use MS is to give teams full control of their apps and cut the amount of cross-team communication required. This is a fallacy, as a well architected solution (either monolith, MS or big services) will share the same characteristics: failure partition/isolation, domain boundaries, low cognitive load etc. I think it's important to mention this as many people struggle to build well architected monoliths, then try to the same with MS and end up with a distributed big ball of mud.

This is an opinion, but a well designed monolith is (usually) better than a microservice architecture (less moving parts, lower latency, considerable easier to refactor, etc). It's easier to start with a well designed monolith and move to microservices than the other way around, mainly because there's a big chance one is going to mess the initial microservice boundaries. Mary Poppendieck suggests the same in some of her presentations (maybe in The Future of Software Engineering?)

It's important to say that even if one builds a monolith, it doesn't mean that everything should be synchronous, and it's fine to use queues/topics or other integration approaches to communicate between the domains in the monolith. Most MS platforms I've seen are actually distributed monoliths. All services have to be deployed at the same time as they are not backwards/forwards compatible. This is the worse of both worls: a more complex architecture for little benefit.

I think your point about sync/async is the key regardless of a monolith or MS architecture. Everything that is not part of the critical path should be done asynchronously to partition errors and reduce latency.

A few more pointers:

• The majestic monolith
• Monoliths vs Microservices is Missing the Point—Start with Team Cognitive Load

Answer 2

It depends on what you are trying to build.

In my opinion, if the application is small enough or is maintained by 2-3 people I would prefer a monolith due to lower latency, maintenance of the code is easier, and you have fewer things to worry about.

But for anything bigger than that you should consider MS, each part of the service can be maintained separately by different people, yes performance drops using MS but it can be optimized enough that the end user does not notice. If you are doing very heavy processing u can scale only that specific part of the service accordingly leaving the rest of the infra untouched.

And for your question about sync vs async as my general rule any service call that can be async should be async. And keep only the core functionality to break the chain of calls.