6

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?

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, 2021 at 13:31
  • thanks @Jesper! that made it very clear Sep 15, 2021 at 6:48

1 Answer 1

6

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.