Services: add or remove services #

Services work well when each service matches a subdomain and is developed by a single team. If those premises change, you’ll need to restructure the system:

• A new feature request may emerge outside of any of the existing subdomains, creating a new service.
• A service may grow too large to be developed by a single team, calling for division.
• Two services may become so strongly coupled that they fare better when merged together.
• The entire system may need to be glued back into a Monolith if domain knowledge changes or interservice communication strongly degrades performance.

Add or split a service #

Patterns: Services.

Goal: get one more team to work on the project, decrease the size of an existing service.

Prerequisite: there is a loosely coupled (new or existing) subdomain that does not have a dedicated service (yet).

If you need to add a new functionality that does not naturally fit into one of the existing services, you may create a new service and maybe get a new team for it.

If one of your services has grown too large, you should look for a way to subdivide it (likely through a Cell stage with a shared Orchestrator and database) to decrease the size and, correspondingly, complexity of its code and get multiple teams to work on the resulting (sub)services. However, that makes sense only if the old service is not highly cohesive – otherwise the resulting subsystem may be more complex than the original service.

Pros:

• You get an extra development team.
• The complexity of the code decreases (splitting an existing service) or does not increase (adding a new one).
• The new service is independently scalable.

Cons:

• You add to the operations complexity by creating a new system component and several inter-component dependencies.
• There is a new point of failure, which means that bugs and outages become more likely.
• Performance (or at least latency and cost efficiency) of the system will deteriorate because interservice communication is slow.
• You may have a hard time debugging use cases that involve both the old and new service.

Merge services #

Patterns: Services, Monolith or Layers.

Goal: accept the coupling of subdomains and improve performance.

Prerequisite: the services use compatible technologies.

If you see that several services communicate with each other almost as intensely as they call their internal methods, they probably belong together.

If your use cases have too high a latency or you pay too much for CPU and traffic, the issue may originate with the interservice communication and merging the services should help. No services, no pain.

Alternatively, as domain knowledge changes [DDD], you may have to merge much of the code together only to subdivide it later along updated subdomain boundaries. Which means you face lots of work for no reason.

Pros:

• Improved performance.
• It becomes easy for parts of the merged code to access each other and share data.
• The new merged service or Monolith is easier to debug than the original Services.

Cons:

• The development teams become even more interdependent.
• There is no good way to vary qualities by subdomain.
• You lose granular scalability by subdomain.
• The merged codebase may be too large for comfortable development.
• If anything fails, everything fails.