We've stuck with designing two services. In fact, these two services have been splitted since traffic issues, so they were one before.

I mean, our platform is consumed by two sort of clients: other services and UI clients (web, desktop and mobile).

So services:

  1. Services are using a very short number of exposed endpoints (addInput, removeInput).
  2. Althought they are using those methods they generates more traffic than clients.

So clients:

  1. Clients are using a very large number of exposed endpoints.
  2. Nevertheless, they are not generating so many traffic.

So, they are sharing code (since they are accessing to the same database), but as far I've been to figure out microservices has no to share base code.

We believe something is wrong using this approach.

I don't know if I've explained so well.

Which would be the keys in order to solve this kind of microservices architecture issues? Is "traffic issue" a key enought in order to split a service?

  • 1
    Is "traffic issue" a key enough in order to split a service?Not really, but could help. Microservices architecture responds to organisational and business needs. It's rather a company's strategy than a solution for technical issues. Microservices usually brings more headaches than those it solves. Could you explain what kind of traffic issues did you suffered before the split?
    – Laiv
    Jul 24, 2017 at 10:02

2 Answers 2


Ok, so the classic problem with your setup is that the high volume calls slow down, or break the low volume calls. or in your case the Services slow down the Users.

The solution is to split the service into two as you have, sort of, done. You can then either scale up or throttle the Service without affecting the Users

As you point out its not recommended to share code across services. I guess you have it left over from when they were one service. And as you say, they are both using the same datalayer.

Now there IS something wrong. But its not so much the shared code as the fact that you are still sharing a database.

Being on the same db means that the high traffic calls can still affect the Users. If you moved them off you would presumably no longer have any shared code.

Sharing code in of itself may give you some maintenance difficulties and you should try to refactor it out if possible. But its not the root of the problem.

You may find that if the high volume service hits performance limits due to cpu or memory rather than database calls then you have already solved your issues by splitting the service at the code level. In that case sharing datalayer code is not a bad thing.

  • Let me ask you for another related issue. Guess two services: serviceOne and serviceMail. Is correct to call an seriveMail endpoint from serviceOne? Generally, is correct calls between services?
    – Jordi
    Jul 24, 2017 at 14:19
  • @Jordi depends, if they chat each other frequently it's probably because their respective "bounded" contexts overlap each other too. Depending on the protocol and the communication interface this could lead you a problem of coupling or inter-dependency. Neither of both is good. That doesn't mean that you shouldn't. Depends on how much decoupling can you afford. A microservice, despite Ewan's opinion the more nano the worse, because it pushes you to chatty services what makes the inter-process communications the hell. (worse, or at least, harder to deal with)
    – Laiv
    Jul 24, 2017 at 14:33
  • @Jordi You might be interested in orchestation vs Choreography as a reference to define your inter-process communication strategy
    – Laiv
    Jul 24, 2017 at 14:33
  • @Jordi finally related to the last question, allowing micro services to send mails related to their own "bounded" context would not violate the separation of concerns. I have seen serviceMails that just were wrapping the SMTP server... Does it make sense? Hard to say, overall when they basically turn SMTP communications into HTTP.
    – Laiv
    Jul 24, 2017 at 14:43
  • If all your microservices are calling each other Its a bit of a code smell if you ask me. In your example, whatever calls serviceOne should be deciding whether it wants to send a mail or not
    – Ewan
    Jul 24, 2017 at 16:11

Assumption: "traffic issues" are a matter of scaling out to cope with additional load.

Ideally yes, you shouldn't use the same code, but more importantly to me, I wouldn't use the same database.

At it's biggest, the size of a microservice is one that encompasses a domain of your business - maybe two services you have are "Orders" and "Customer". The "Orders" service can talk to your "Customer" service via an agreed protocol - but they don't need to integrate at the database level. The reason you do this is because it lets you have two independent but communicating teams of developers. I would check that the "services" you have decided to split out are similar to this size.

An "Order" might be created that needs a customer's current address to ship an item - so it talks to the "Customer" service to get that address. However: "Orders" stores it's own copy as it belongs to the "Order" - not the "Customer".

The simplest model is one service owns some piece of data - nothing besides that service should update that data. You should behave as if you have no control over the data or interface of the other service even if you do because you could break existing clients.

Microservices have a couple of overheads:

  • Versioning the interface (so you don't cause problems for clients)
  • Cleanly isolating data to separate services and databases
  • Service discovery / commmunication - "How do I talk to other services?"
  • and I'm sure I'm missing a few.

If you don't do the above well, you also have further complications with deploying your software as you'll need to co-ordinate deployments of multiple services.

If you have a well-architected code base, you can just change the implementation of methods to talk to your new (external) service. If you don't, this will be a much more difficult journey.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.