2

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.

Improve this question
4
  • 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. 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? Commented Oct 24, 2022 at 1:45

2 Answers 2

Reset to default
1

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

Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.