0

In the standard micro service API gateway pattern (if you research any major site discussing this pattern ) you will see the same api gateway pattern in which one or more API Gateway(s) sit in front of one or more micro services and communicates with them via HTTP/REST or gRPC.

Here is one sample image of this api gateway design pattern and the source for it below.

Api gateway pattern

image reference: https://devblogs.microsoft.com/cesardelatorre/designing-and-implementing-api-gateways-with-ocelot-in-a-microservices-and-container-based-architecture/

This design concept is very heavily documented online and so i wont add anymore detail to that design concept here.

We are looking to implement an API Gateway pattern for our micro service architecture.

The above design pattern is for certain an option we have reviewed but we also considered a different option in which the gateway would be fully decoupled from all micro services by sticking a publish/subscribe event bus in the middle of the architecture between the API Gateway and the micro services themselves.

In this design concept, the gateway would publish messages directly onto the event bus and the micro services would subscribe and process these messages. They would communicate back to the bus and the API gateway would subscribe to those messages and (in theory) then return to the calling client over https.

The gateway and micro services would not speak to each other or be coupled to each other in any way.

enter image description here

I have not seen an API gateway pattern that speaks directly to an event bus like this and I am guessing that there are reasons why and that we are not considering all of them.

I am guessing that there may be two immediate reasons that I can think of:

  1. the http response to the client would have to somehow wait on the subscribe event so that it could return data to the client. I am not quite sure how this would work without messing with some code.

  2. The API gateway would seemingly have to subscribe to a 'plethora' of events as it communicates to the event bus and the event bus is being monitored by various micro services. As the number of microservices grows, the number of events that the gateway would need to subscribe to would also grow and it feels like this code could grow quite large in the gateway.

Could anyone with API gateway pattern experience speak to this concept of communicating directly to an eventbus instead of to the microservices directly?

Matt
  • 1,168
  • 2
  • 15
  • 24
  • do you need the capablities that come with asynch architecture? – akaphenom Dec 16 '21 at 20:02
  • No we do not. The only reason for looking at this concept was just seeing if we could fully decouple the gateway from any 'semi-direct' connection to the services themselves and try to move toward more of an event driven architecture. – Matt Dec 16 '21 at 21:35
  • is gatewaya. commercial product or something you would build? Also how would that scale in the asynch model? I have built event driven apps bridging kafka to websockets (to the application) - it gets complicated fast. I think the first model is more straight forward and doesn't preclude you from moving to asynch when you have a need or more confidence in the solution – akaphenom Dec 16 '21 at 21:38
  • thank you - regarding your first question - In our basic research so far it doesnt appear that most commercial api gateways such as NGINX, Kong or Ocelot support a dump to an event store/event bus out of the box and so we would expect to have to develop the gateway in-house. In regards to your second question, what specifically would be the issue that you see scaling out in the async model? Could you be more specific? thank you – Matt Dec 16 '21 at 21:53

0 Answers0