Macroservices

Essence

Macro-services emerge from incorrect microservice decomposition and significantly complicate development. They are oversized microservices responsible for too many processes that could have been separated.

Macroservice

A macroservice appears when a single service combines multiple loosely related business processes.

To identify weak coupling, clearly define what the service actually does — the specific business problem it solves in one sentence. If that sentence contains an “and”, it’s a clear sign the service handles unrelated processes.

When these processes are decoupled, a new business model can emerge that differs from the original one.

Symptoms

• The model becomes large and difficult to develop
• Several teams work on the same service simultaneously
• Many dependencies on external services

How to fix it

Define the service’s area of responsibility and design the minimal model needed to function within it.

Let’s look at a messenger application and its user service.

This service manages the user: their chats, contacts, account settings, blacklist, etc.

But why does managing account settings require knowledge about chats? Why should the blacklist involve chat groups?

A key problem is the growing complexity of the model — for example, if we want to add a whitelist, split contacts into “registered” and “spontaneous,” or introduce a message deletion timer, the user model would become even heavier.

That’s how weak coupling becomes visible. Let’s decompose the user service.

Decomposition

I split the services into three, each with its own responsibility:

• user account management — handles account settings
• social — handles interactions between users
• chat — handles messaging

With this structure, the processes and dependencies inside each service are easier to understand. By increasing granularity, each team can own a separate service without overlapping in their work.