What are your thoughts on having a service/process be both an API server and a background worker, consuming messages off a queue like SQS?

I have typically kept these two separate to keep single responsibilities for each, but also it seems weird, at least in NodeJS, to have an API server bootstrap itself to be an API server but then also start polling a queue for jobs to be done.

Is it a fairly common practice to mix the two into the same service? If not other other strong reasons to keep them separate? Also somewhat tangential but would the same logic apply for an API server and a Kafka consumer?

1 Answer 1


In microservices, it is common to have the service responsible for a bounded context. For example, as User Management Service would handle all interactions related to users in your system. That means the service would handle all database interactions along with sending notifications on a queue if necessary. (for example, user logs out so notify all services in case there were record locks the user had open)

There are patterns where you may separate responsibilities. For example Command Query Responsibility Separation (CQRS) has one service for the simple Create, Update, Delete functionality for your bounded context, and a separate service for reading, querying or searching information in that bounded context. A good reason for separating those concerns is if the format for storing state is very different than the format for querying that state.

General Rules of thumb:

  • Clearly define the bounded context for your service--data/notifications/etc.
  • If two services are so intricately tied that one cannot function without tight integration with the other, then chances are you have drawn your boundaries incorrectly

We commonly have services that both interact with a database, send events and respond to events because the bounded context is for the data the service represents, not the functionality of the service itself.

  • Thanks for the response Berin, that's quite interesting. We are starting our journey with Kafka (event driven architecture) and microservices, and for the notifications domain I have 3 services, one consuming events off Kafka, an API service that contains business rules and has a db to store notification settings and then a worker to process notification jobs off SQS. You have implemented something like this as a single microservice that does all 3 responsibilities? Can I ask what language/framework it was written in and any performance or other issues you may have run into?
    – n00b
    Commented Jun 29, 2021 at 23:18
  • Our team is Java Spring Boot based on the back-end. The back end only deals with JSON objects, so after we update the database, we send a message on the queue so other services that need to know the information has changed can be notified. Commented Jun 30, 2021 at 2:17
  • Is the Spring Boot application also a background worker (poll and process messages off the queue)?
    – n00b
    Commented Jun 30, 2021 at 5:52
  • Spring Boot has APIs to essentially provide a queue to send messages, and let you register a callback for your service to respond to. The plumbing of actively receiving the message is done for you, and you simply provide the handler in the microservice. Commented Jun 30, 2021 at 12:18

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.