My team is torn with how we should architect our microservices with using a message bus.
We currently have an API Gateway with many microservices behind it all communicating over http.
After looking into implementing Message Buses (Kafka) the team is torn on whether the consumer and API should live in the same service or if they should be two separate services.
Some think they should be separate as they have different scaling concerns, while others think they should be in the same service since they are communicating with the same database and have the same domain concerns. IE) Not duplicating code between two services.
What are your thoughts?
My take on this is that the Webapi should be in one process and the Message Consumer should be in a separate process. However, the collective of the two processes is ONE Microservice. That is, you should deploy them together as one unit and you can share the domain between the two (as it is still one microservice).
The above microservice example is still focused on ONE business capability/bounded context , even though it is made up of two processes.
I think it's important to make the distinction between Business Capability and Software Capability when thinking about bounded contexts. The processes in the example above may have different software capabilities (one takes in web requests and one consumes messages), but together they complete a single business capability.