We need a mechanism in place to limit API usage

[jcrossley3]

Some of our queries are very expensive, but even after optimizing them, we'll need to be able to limit users' interaction with the database through our API, whether from trustify-ui or otherwise.

[JimFuller-RedHat]

sure, but this is this a layer 7 concern ? why bake into the app any notion of throttling when in reality we would use other infra (nginx, etc) to do this

[chirino]

We should use something like envoy to enforce api limits.

[chirino]

And redis cache to reduce the cost of commonly hit endpoint resources.

[JimFuller-RedHat]

nginx (and plenty of other stuff) can negotiate/cache as well ... FWIW all I am saying is that the trustify app should be as simple as possible and we leave other complexities to other layers/infra (if possible).

on the db side we already have well designed caching .. usage of pgbouncer and read/write replicas is the infra solution on that side of the 'equation'.

[jcrossley3]

sure, but this is this a layer 7 concern ? why bake into the app any notion of throttling when in reality we would use other infra (nginx, etc) to do this

If there's a better repo for this issue, lemme know and I'll move it. I'm ignorant of the ideal mechanism, just know we need something.

[chirino]

Agree @JimFuller-RedHat we could start with a dumb http reverse proxy that uses response cache headers to do simple cache control. It does mean we need to set cache TTLs on our API responses.

The downside to this easy approach is we wont be able do eager cache invalidations when ingestion occurs.

[ctron]

I like the idea of using existing tools and mechanisms for this. As the few comments show, this might have an impact on the API (like invalidation and headers). There are pros and cons.

Which leads me to believe that his would be worth another ADR. Discussing things before performing any implementation work.