CODEWITHSUNDEEP
c#restkubernetesrabbitmq
TopBanana9000
TopBanana9000

Reputation: 898

RabbitMQ, REST API, Docker, and Kubernete Best Practice Question

This is a high level question that I am asking for something I am currently architecting and cannot seem to find the exact answer I am looking for.

Scenario: I have a .Net Core REST API that will be receiving requests from an external application. These requests will be getting pushed into a RabbitMQ instance. These notifications will be thrown to an exchange, then fanned out to multiple queues for multiple consumers.

There is one consumer that I will be responsible for and I am looking for advice on best practices. Ultimately, there will be a REST API that will eventually need to react to these messages being pushed into the queue. This REST API in question is a containerized (Docker) app running on a Kubernetes cluster. It will be receiving a lot of request traffic outside of these notifications (queue messages), making SQL calls, etc.

My question is, should I have an external microservice (hosted service/background service) that subscribes to this queue with the intent of calling into said REST API. Kind of like a traffic cop; routing messages to the appropriate API method based on certain data points.

Or

Would it be OK to put this consumer directly into the high-traffic REST API in question?

Any advice around this? Thanks in advance!

Upvotes: 1

Views: 404

Answers (1)

Rico
Rico

Reputation: 61571

There is no right or wrong. This is the whole dilemma around monolith-microservices and synchronous-asynchronous.

If you are looking at going with microservices and more asynchronous, you can start with these questions:

  • Do you want your system into different codebases?
  • Do you want to divide responsibilities among different teams?
  • Do you want to use different languages/projects for the different components?
  • Do you want some components of the system to respond faster to the user?
  • Can your app be ok with the fact that one decoupled component may fail completely?

should I have an external microservice (hosted service/background service) that subscribes to this queue with the intent of calling into said REST API. Kind of like a traffic cop; routing messages to the appropriate API method based on certain data points.

Yes, if you are thinking more on the microservices route and the answer is 'yes' for most of the above questions (and even more microservices related questions not mentioned).

If you are thinking more about the monolith route:

  • Are you ok with the same code base shared across the different teams?
  • Are you ok with a more unified programming language?
  • Do you want to have a monorepo? (although you can do micro-services with monorepos)
  • Is the codebase going to be mainly be worked on by a few people who know it really well?
  • Is it easy to provide redundancy within the app? i.e If one component fails the application doesn't crash.

Would it be OK to put this consumer directly into the high-traffic REST API in question?

Yes, if your code can handle it and you are more in line with 'yes' on the answers above.

Upvotes: 1

Related Questions