Assumptions and Questions for Serve Vriddhi Deployment and Scaling

[Sowmya-Raghuram]

A few assumptions from the engineering team

1. The first version (that we are working towards) will be deployed on AWS.
2. It will have a few infrastructure components that will be AWS specific.
3. Each partner will deploy and maintain their own instance of Serve, on their own AWS accounts.
4. For a partner to deploy this on AWS, it will be relatively simple, they have to run a few scripts, and the service should be up and running.
5. Alarms and monitoring will also be added on AWS.
6. For a partner to deploy this on another cloud platform (gcp / azure), it will take additional engineering time to set things up.

A few questions now:

1. For a deployed version, what is a reasonable upper limit for the number of schools / organizations that will be using it. We can approx. it as order of 100s / 1000s of schools etc.
2. What can be a reasonable assumption for transactions per second (or minute). This will tell us how many reads / writes can be expected on the APIs we are building, hence insights into scaling.
3. What is the max data size (volunteers / coordinators / students ) per instance. This will give us insights to data size per instance.
4. Our first version will be deployed on Evidyaloka AWS account, will this be just for demo / proof-of-concept, or we will use this for launching our first set of partners.
5. A few public-apis should be ideally on evidyaloka aws a/c, so any deployed instance (elsewhere) can post non-uci information centrally, so we can gather usage stats etc.
6. We should have some way to announce major version releases etc. so some process exists for release management, just an email-list perhaps, so partners can perform testing and upgrades if needed.

Kindly continue this thread for any further discussions or updates related to Serve deployment, scaling, and release management.