I'm working on an application implemented in different microservices, which uses a message broker (event bus) to consume events (simple pub/sub).
As for now, in a given microservice, we are spawning 1 thread per event subscriber, which will be running in background checking for new published events (specifically) to process. I was told that the idea behind this approach is to avoid one event consumer to shutdown other subscribers in the case of an unhandled exception in the processing of this specific event.
The problem as I see is that this approach doesn't scale well. As our application grows and different events are created, this list of active threads will grow as well.
I think we should stick with 1 background thread responsible for handling any new event needed by a given microservice and handling the processing of an event in the same thread via async/await or use a queue to dispatch the processing of each event; and implement strategies to ensure that this thread will keep alive for the duration of the application.
Which approach is better in this scenario? One thread per event subscriber or 1 thread for processing all events?