0

If I have two APIs that I'm considering to be two separate micro-services, each with their own database, how would I handle worker processes for each of these micro-services?

For example, if each API would launch a long running task that needs to be handed off to a worker, should these two APIs share the same worker pool? Or should they each have their own pool of workers, but share a messaged broker, using separate queues?

Spinning up multiple sets of workers seems to be the easiest way to keep everything isolated as necessary, but also seems somewhat inefficient in terms of resources, as it requires. What would be the correct approach?

Improve this question

1 Answer 1

Reset to default
6

Spinning up multiple sets of workers seems to be the easiest way to keep everything isolated as necessary, but also seems somewhat inefficient in terms of resources, as it requires.

Performance is not the main focus of microservices. This is a commonly misunderstood nuance.

Going by the traditional optimization focus on single-request performance (i.e. how long does it take one request to be resolved?), microservices would actually be judged as relatively underperformant. You need multiple machines, your databases are separated and cannot benefit from join optimizations, a single request (to the user) may warrant several calls to separate microservices, ... All of these separations incur the overhead cost of their respective communication layers.

In regards to your question, the inefficiency you're focusing on is not what you should be fixating on in your microservice architecture.

What microservices lack in single-instance runtime performance, they more than make up for by having a much simplified release process, rigorously enforced lack of tight coupling, and the ability to scale services based on concrete usage (without needing to scale services that aren't in such high demand).

In order to maximize these things, the better choice here is to keep your workers isolated, as it maximizes the independence (and therefore also scalability) of each individual microservice; which is precisely the strength of a microservice architecture.

Improve this answer
3
  • Awesome, thank you for the response! Just out of curiosity, would it be considered "acceptable" to have a central messaging server, like a central RabbitMQ server, that hosts several queues, each of which are used by different microservices? Or should that be separated as well?
    – BobS
    May 16, 2022 at 14:21
  • @BobS: With every step, there's always a purism consideration. Purists will keep everything isolated, whereas others see room for compromise. If your message broker is sufficiently provisioned to handle any reasonable load (and will be scaled up if the limits are ever met), I see no reason to label it as an invalid approach.
    – Flater
    May 16, 2022 at 15:05
  • @BobS You always need some network and some service discovery to get the services to talk to each other – total separation is infeasible. Using DNS + direct requests is one way to do that. Using a central message queue is another well established way to structure communication. A message broker will be particularly useful if your services generate events that shall be consumed by multiple other services, or for other event-driven architectures. Direct messages between services will be more useful if you're expecting a synchronous response.
    – amon
    May 16, 2022 at 21:22

Your Answer

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

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