Should my microservices share the same database or communicate via a messaging service

Question

I'm looking for general guidance on my systems design.

I currently have two services:

• Vendor service that is connected to a Mongo database which contains specific Vendor data and including their twitterids
• Twitter service that has no db connectivity but listens to live twitter feeds of specific vendors. Once there is a new tweet the Twitter service processes the tweet and sends it back to the vendor service for storage via a message queue.

Problem: The Twitter service upon startup doesn't know what vendors to listen to because it doesn't have access to the database of Vendors.

My Solution: Upon startup the Twitter service sends a message to Vendor service requesting a list of all the Vendor Twitter ID's to listen to. The Vendor service upon receiving the message then gets all the Vendor Twitter ID's from the database and sends the list back to the Twitter Service via the message queue. The Twitter Service then begins to listen on those Vendor's feeds.

My question is, is my solution correct or would it just be easier for the Twitter service to connect to the mongo database. I think the one plus in my solution is that if I want to scale up the Twitter Service the Vendor service can manage which Vendor ID's get sent to the Twitter service to listen on. I'm just not entirely certain any second opinion would be appreciated.

Answer 1

My opinion, worth everything you are paying for it, is that you are on the right track.

With the Twitter service asking the Vendor service you get these benefits:

• You can enforce any access control you may need at the service request boundary
• You can change the database (or anything else) on the Vendor service side without disturbing the Twitter service.
• You can still send in the request if Vendor Service isn't running yet (remove problems based on the order of startup).

Sounds like you're doing well... keep going.