I have a use case to create a service that consume messages from a message queue, process them, store them in the DB, and expose the processed results via an API. Therefore, the service I'm going to create will have to have both an API as well as listen to events.

I want to clarify if this is an anti-pattern in a microservices architecture and should avoid. If I should avoid this, what alternatives do I have?

PS: I'm reaching out to the professionals here, as I couldn't find a proper answer googling.

  • What you've described sounds like a typical api. What kind of "events" are you listening for? Commented May 26, 2022 at 19:01
  • @joshmeranda The service would need to consume the messages from the message queue, which the service then process and make the processed result available via an API.
    – Deepal
    Commented May 26, 2022 at 20:08
  • You're tying your services to an entrypoint, not necessarily bad... but probably other architectures could help. If the API is an entrypoint, and the queue is an entrypoint, make a service that deals with both, you can use a simple MessageBus to centralize these requests. If you need a sync API you can also cache to redis and return without the client pooling your endpoint. It tends to be more common to have a consumer/worker and an API running separately (single codebase), but I guess you could get away with multiprocessing or something depending on your language and load. Commented May 27, 2022 at 2:21
  • Does the service poll for event off the bus? Or do the events get pushed to the service?
    – Flater
    Commented Oct 24, 2022 at 1:45

2 Answers 2


No, that's not an anti-pattern. It sounds like you are doing some sort of CQRS (Command Query Responsibility Segregation), with the service you describe (gathering the data from events and providing a way to query it via API) being the read side. To quote Martin Fowler:

It's common to see CQRS systems split into separate services


I wouldn't necessarily call it an anti-pattern but depending on how the queue receives the events it might be better to separate both operations into their own microservices.

If the work queue is to be filled by data from some client it wouldn't be unreasonable to keep the processing logic internal to the api. The api receives data, processes it, sends it to the database, and returns the data to the client. Depending on how persistent the data needs to be you might not even need the database at all in this case.

If the work queue is self-populating or receives its processing queue from another internal source, it would make more sense to separate the queue processor and the api. One microservice to process data and send it to a database, and another microservice serving an api which handles requests, query the database, and return the data.

+-----------------+    +-----------+    +-----+    +--------+
| Queue Processor | -> | Database  | -> | Api | -> | Client |
+-----------------+    +-----------+    +-----+    +--------+ 

In short, it the queue and API are inherently coupled it makes sense to keep everything tied together, otherwise it would be better to separate those concerns and develop them as individual microservces.

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.