1

I found this resource explaining decompose by subdomain where one of the disadvantages is "Can create too many microservices, which makes service discovery and integration difficult."

I'm a bit puzzled with what that really means in layman terms, so it would be great to hear a different explanation of the same disadvantage.

Thank you in advance!

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
Mahir Hiro
  • 135
  • 1
  • 7

2 Answers2

1

The core concept of this disadvantage relies in the term subdomain, which sometimes can be fuzzy to truly understand it, mainly because it's on that border between business and engineering. A similar term for it is bounded context, and this article gives a pretty good explanation of it.

For example, in an e-commerce application, we can have the following subdomains, which can be easily mapped to individual microservices:

  • The Payment subdomain
  • The Order subdomain
  • The Authentication subdomain
  • The Search subdomain

However, in a more complex application, where the majority of components are tightly coupled (monoliths), it's not always so clear where to draw the border between some subdomains. You need business knowledge and good documentation (or ideally, access to the original authors of the application), in order to properly get this right.

For that reason, you may end up creating too many subdomains, which may translate into too many microservices (one subdomain can have multiple microservices), and this has it's own disadvantages (we're talking here about tens of microservices or even more).

One of them would be routing a request to the proper microservice, or properly orchestrating the calls when you got a call which needs to translate to a number of downstream calls, for example (on the e-commerce app):

  • The user is logged in and wants to search for a product (makes a request to your API gateway)
  • The request is routed first to authentication microservice to check the token received on the request
  • Then, the request is routed to the search microservice to retrieve the actual data
  • A final request is launched to the profile microservice to get the existing shopping cart items, to be displayed in the top right corner of the page.

Of course that things can be cached to avoid extra calls, but that's just a possible sequence so you can make an idea.

Cosmin Ioniță
  • 3,598
  • 4
  • 23
  • 48
  • Your example flow is not correct. 1: the authentication microservice shouldn't be a part of the flow - his sole role is to create authentication tokens. The token is signed and has an expiration date, each microservice should have a private key to check if the token is valid without asking the authentication microservice. 2: search should be the sole recipient of the request (after routing in API gateway) 3: Profile is the wrong domain name for holding the shopping cart and it's not part of what the user was asking for. If you want to display do a separate request. – Maciej Pyszyński Jun 28 '21 at 13:53
  • @Cosmin, thank you for the detailed answer. From my understanding, the real disadvantage is "creating too many subdomains, which may translate into too many microservices." But apart from the extra calls, you did not mention what the disadvantages were. Would you mind elaborating on that? – Mahir Hiro Jul 04 '21 at 16:22
  • @MahirHiro Multiple microservices simply involve that your system has multiple moving pieces, with maybe different performance requirements or different integration protocols. Keeping track and simply managing them is a challenging task. That's the main disadvantage of having multiple microservices. Let me know if this helps – Cosmin Ioniță Jul 07 '21 at 06:54
  • 1
    @MaciejPyszyński Thanks for pointing that out, you are completely right - I was a bit in a hurry when trying to craft the example. However, in my example I was trying to emphasise the number of calls can be generated by a single request, to illustrate the impact of having multiple microservices. – Cosmin Ioniță Jul 07 '21 at 07:00
0

The first issue is in the assumption that each subdomain should be handled by a separate microservice. Some of the subdomains could be bundled in one modular monolith - especially those which require fast responses or/and have a lot of communication.

And now we get to the point of why:

  1. Microservices communicates over the network - do you handle all kind of issues related to this - timeouts, no responses, services being unreachable
  2. No possibility to do transactions. Then you should generate a lot of events - subject accepted, subject rejected for each microservice that is a part of the initial operation. If something goes wrong every action should be reverted in each microservice generating more events to be handled :)
  3. Communication over the network is costly when you need to get some data from another microservice and you do this frequently, then the cache should be created on the questioning side much earlier than in the monolith.

Basically by adding the network layer to your app doesn't allow you to use transactions, while each microservice mutable request should be still atomic (transactional). Having too many microservices creates way many more complex problems in comparison to the monolith.

BTW. If you cannot split your domains inside a monolith you'll fail so much more with microservices by adding network issues.

Maciej Pyszyński
  • 9,266
  • 3
  • 25
  • 28
  • Thanks for your comment, however, what is still unanswered is the "service discovery issues". If service discovery/ registry is automated using some pattern where each microservice responds and stores their locations in some table, why does having more microservices become a disadvantage? – Mahir Hiro Jul 04 '21 at 16:17
  • Because you need to handle more cases of network issues than doing it one microservice - no communication issues there – Maciej Pyszyński Jul 09 '21 at 13:47