5

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?

Eslam Nasser
  • 61
  • 1
  • 2
  • 3
    The main difference between using a HTTP REST API vs. message queues (RabbitMQ) is synchronous vs. asynchronous. Synchronous = you do a request, wait for the answer and process it, which is how HTTP REST normally works. Asynchronous = you put a message on a queue for another system to pick up, you don't want for the answer. Either can work, you'll have to think about what's best for your software. – Jesper Sep 14 '21 at 13:31
  • thanks @Jesper! that made it very clear – Eslam Nasser Sep 15 '21 at 06:48

1 Answers1

5

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....

LoztInSpace
  • 1,149
  • 6
  • 8