REST APIs vs Message brokers for Backend to Backend communication

Question

We are a wholesale marketplace and we have three main products in our startup. The products are:

1- the marketplace app that allows customers to view products and purchase online.

2- the seller app that allows the sellers to list their products and see review incoming orders.

3- the courier app that allows drivers to receive order requests and then they do the fulfilment.

We are planning to have those three products separated so each product will have its own team, its own backend, and frontend. Each product may have a different tech stack.

My question is how these products shall communicate. We are considering two options either using API or using a message broker such as RabbitMQ.

What do you think about which options should we consider?

Answer 1

Message broker will allow your systems to be offline at different times without rendering the ecosystem unusable. For example you can add a product without the marketplace being available (assuming the market will subscribe to new products). Pub/sub also allows for a nice way to notify future components of activity with little to no changes or integrity issues.

You can do both though. Nothing wrong with, for example, providing APIs for enquiry but implementing an action or command with a queued message. This can work so long as your implementation is robust against an API being unavailable (e.g. "cannot find the current courier availability for your area").

As an aside, I'd question whether having (wildly) different stacks within the same company is a good idea unless you have a great reason for that. I suspect you also plan to have different databases for each part. That approach will solve some potential issues but will cause a set of different problems to having all or even just some data in same DB. Anyway, that's not what you asked and I don't know your business, but....