Is RabbitMQ's RPC with a REST API Gateway a recommended practice?

[Salvatore Garbesi]

We have a Public REST API Gateway (~1000 req/s) that when called, communicates to a Private Microservice REST API to gather the data it needs for the client response in a synchronous manner.

Client ----> Public REST API Gateway ----> Private Microservice REST API

Instead of going directly from the Public REST API Gateway to the Private Microservice REST API, we instead were interested in using RabbitMQ's RPC. We need to send the response back to the client in a synchronous manner but were uncertain how this would handle at volume/scale.

We know it's possible to achieve this functionality with RPC, however, it's unclear whether this is the intended use of this functionality or not. Any insight would be extremely helpful.

Thank you in advance.

[Artur Wroblewski]

On Wed, Jan 04, 2023 at 03:00:35AM -0800, Salvatore Garbesi wrote:
> We have a Public REST API Gateway (~1000 req/s) that when called,
> communicates to a Private Microservice REST API to gather the data it needs
> for the client response in a synchronous manner.
>

> *Client ----> Public REST API Gateway ----> Private Microservice REST API*

>
> Instead of going directly from the Public REST API Gateway to the Private
> Microservice REST API, we instead were interested in using RabbitMQ's RPC.
> We need to send the response back to the client in a synchronous manner but
> were uncertain how this would handle at volume/scale.

I have tested similar design with RabbitMQ Streams and I was able to
achieve several thousands of messages per second in a single threaded
application on a laptop. This was without batching - each message was
confirmed by RabbitMQ broker, so a client knew its request is in the
system.

Therefore, I believe, you should get similar performance with normal
queues. I would consider RabbitMQ Streams though, i.e. if your client can
"batch" requests, then you can get better throughput.

[...]

Best regards,

Artur

--
https://mortgage.diy-labs.eu/