I'm working on a system that implements multiple microservices which communicate via a RabbitMQ messaging bus.

  • These microservices are created using python with the pika library (to publish messages as well as consume a RabbitMQ queue)
  • One of these microservices (let's call it 'orders') has a connected database to store data

So far, the application components are asynchronous relying fully on RabbitMQ exchanges/queues for communication and, when needed, implements callback queues when one microservice needs to request data from another.

Now that I have backend microservices talking to each other, I would like to implement a RESTful API interface for this 'orders' microservice so clients (ex: web browsers, external applications) can receive and send data.

I can think of two ways to do this:

  1. Create another microservice (let's call it 'orders-api') in something like flask and have it connected to the underlying database behind the 'orders' microservice. This seems like a bad idea since it breaks the microservice pattern to only have a database connected to a single microservice (I don't want two microserices having to know about the same data model)

  2. Create an 'api-gateway' microservice which exposes a RESTful API and, when receiving a request, requests information from the 'orders' microservice via the messaging bus. Similar to how RabbitMQ documents Remote Procedure Calls here: https://www.rabbitmq.com/tutorials/tutorial-six-python.html. This would mean that the 'api-gateway' would be synchronous, and thus, would block while waiting for a response on the messaging bus.

I'm not sure if there are other ways to achieve this which I'm not familiar with. Any suggestions on how to integrated a RESTful API in this environment would be appreciated!

  • 1
    There isn't a rule in micro-service design that each micro-service has its own database/datastore. In fact often your DB itself can be considered a micro-service (it does one thing well and has a public interface layer with SQL) and to keep your architecture DRY you don't double them. So I wouldn't decide not to do this just because you think it is a bad design. You say you don't want to do it as well as you don't want different micro-services knowing about the same data model. Is there a reason for this other than you think it is bad design? Jan 22, 2020 at 9:37
  • please don't cross-post: stackoverflow.com/questions/59851992/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..."
    – gnat
    Jan 22, 2020 at 12:19
  • Is there a reason you're not considering the "add an API to the orders microservice" option? Jan 23, 2020 at 12:32

2 Answers 2


I see what your are saying. I do have a few objections though.

a) The gateway will not be synchronous. Asynchronous programming e.g. nodeJS sends a requests and when a response arrives it executes any code on the callback. So you just need to have asynchronous requests on the API gateway. Search for a asynchronous requests" in the programming language you are using.

b) The orders component can have an API interface as well. There is no constraint on this. It will just have an API and an events interface. Using a gateway serves mainly other purposes such as service discovery, single point of contact and other. What I am trying to say is that you will decide to use a gateway for different purposes other than developing an API.

Hopes that helps.


Not quite sure if I understand correctly, but another possibility would be to make the REST Api asynchronous by just having two endpoints, one for submitting and the other one for polling the status. The handler for submit would return a http status accepted, and then you start polling whenever you feel like it. Another possibility would be to use serverside events or websockets.

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.