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.