What architecture would you recommend for a high availability REST API?

Question

.NET

Good afternoon!
I will describe the situation. She's probably pretty ordinary, but still.
There is a rest api and a backend on physically different servers. Authentication and authorization happen on the backend. There is a high chance that the backend may periodically go down for a short time. Therefore, it is necessary that during these periods of unavailability of the api back, the layer does not lose requests, and when the back turns on, it would process them. Another task that I would like to solve is to at least slightly smooth out the load on the api, since there are peaks. The line comes to mind. But because of authentication, as far as I understand, it is necessary to add messages to the queue even before authentication is checked.
What architecture would you recommend in this situation?
The above is implemented on the stack: IIS, .Net WebApi, WCF
Thank you!

Answer 1

They did not indicate what type of authorization and authentication you have and what role the "backend" plays in this process in relation to the API.
I will assume that session-based authorization and the backend stores exactly session data, then you need to use authorization tokens, for example JWT .
Thus, the API layer will not have any connection with the backend when authorizing requests (namely, authorization), because all the necessary data will be "hard-wired" in the token.
If your API layer serves only to display (proxy in some sense) RESTful requests to an internal API or protocol (I understand that WCF is in your stack about this) and you just want to save requests to the server (which should, apparently, be more write than read), use a middleware that will make it possible to queue these tasks.
Software examples: Redis , Beanstalkd .
In the first one, use the LIST data structure, and the second one is just for this and sharpened (do not forget to set up persistance so as not to lose data).
But since you have Windows, then something like hangfire.io is probably more suitable
However, the above software has forks and binaries compiled under Windows.
As for the peaks - that's why they are peaks. Apparently, this is the nature of the activity of your users.
In this case, I would simply analyze the nature and time of occurrence of the peaks and think about how to solve this problem by simply providing additional capacities for this and scaling the on-demand workers, i.e. as activity occurs, we increase capacity, as it decreases, we decrease it. But this is more of an infrastructure issue.
It is even possible that it can be solved through Rate Limiting. Either on your own, or with the help of services like Apigee: docs.apigee.com/api-services/content/rate-limiting.
Unfortunately, I won’t tell you exactly on the .NET stack, because I myself work in a different stack. But the principles here are general.