Data replication via message broker or built-in replication feature?

Question

I'm working on a microservice system where 8 services share the same data - most notably: auth, forum, portal.

Essentially, forum and portal use users from auth, and since I went with the 'AP' approach in CAP Theorem - I duplicate data from users and store it in database of forum and portal whenever it changes - thus removing SPoF if auth dies.

Now, currently I do it by using a message broker (rabbitmq) to listen to UserCreated, UserDeleted and UserUpdated events - from which I get the data.

Should I be doing it this way, or should I use a replication feature built into Postgres? I imagine that my approach allows for replication across multiple database types, be it: MS SQL, Postgres, MySQL, NoSQL or NewSQL solutions.

Answer 1

The main difference between the two is that messaging allows you to apply transformations and enrichments to the data being replicated whereas straight up database replication requires the database schema to be identical (or extremely close, depending on the software).

If you can use database replication, it might be time to ask why you are looking to split up the database in the first place. You may not need to have separate data stores and your architecture might be simplified by using a single database across microservices. I am aware of the literature indicating this to be a Bad Thing (TM), but this is written from the perspective of larger systems with the need to individually scale components. If this does not apply to you, a single database (or replica set) might just make sense.

If you have very different perspectives on the data and are transforming it for faster access in the other microservices, messaging is the preferred choice. I would definitely avoid using messaging to create an exact replica as it would be work without value.