Ory Kratos best scaling practice under heavy loads

[sahinkekevi]

Hi,
We need to scale Ory Kratos horizontally with Postgres on AWS cloud. For example Kratos' login flow produce flowId and update&insert different tables and we can just scale Postgres with read only instance horizontally. Is this a problem for Ory Kratos or we can scale without any problem using Postgres master-write and slave-read instance scalability.
Is there a best practice or different architecture (such as using cockroachDb) anyone can suggest us for scalability under heavy loads.

[vinckr]

Hello @sahinkekevi
Ory Network uses a scalable architecture with Ory Kratos, you can learn a bit about that in this talk from Ory Summit 2021: https://youtu.be/3veok1v4LfE (keep in mind that it has changed quite a bit since then, but it might still be interesting.
I think its not a problem to scale Postgres horizontally.
What request numbers are you dealing with aprox.?

[sahinkekevi]

Hello @vinckr
We're counting down for release of International VOD(video on demand) platform. First we'll be available only for domestic customers, it'll be global for many other countries in short time. Our old domestic version TRTIzle (different architecture and only available for domestic) has requests 50million/day for IDM endpoints.
For our IntVOD platform we have load tests results on AWS for LOGIN endpoint (kratos API clients and clients without browsers):
ApiGW —> 2core 2gb ram —> 40 container
Auth —> 0.5core 0.5gb ram —> 200 container --> our authentication microservice go-gin
Kratos—> 1 core 1gb ram —> 275 container
Postgres--> 8 core 64gb ram
Result: 820 RPS max.
We scale all our microservices, apigw, lambda vs together with dev-ops team (using AWS, kubernetes, ARGO, CI-CD pipelines vs) similar automation tools you suggested on your answer.
We wonder are there any benchmarks for Kratos endpoints.
My second question is can we bypass Kratos flows for login for example using identityApi. What we've seen for login flow approximately 20 different sql query ran on Postgres (including a few insert) which cause locks on tables and we can't use secondary Postgres nodes which are read-only.
thanks for your concern..