Skip to content

Instantly share code, notes, and snippets.

@parthibx24
Last active October 23, 2025 22:03
Show Gist options
  • Select an option

  • Save parthibx24/8e8c1f8252430be59a4e2ef42f3bf3d3 to your computer and use it in GitHub Desktop.

Select an option

Save parthibx24/8e8c1f8252430be59a4e2ef42f3bf3d3 to your computer and use it in GitHub Desktop.
scaling in stages

Minimum scaling features on each stage of a saas production timeline.

MVP Stage (1x users)

  1. Rate Limit in VM (traefik/nginx): for backend+frontend, manually set req/sec.
  2. Db redis cache: for backend (Optional, but this always helps)
  3. Frontend, Backend, DB each should have their own container (Docker is ok)

Doing this would keep the product functional for atleast some users. but it is better to write tests/benchmark script to find the optimal req/sec value for the specific vm config (not sure).

Production Stage (Has few/10x users)

  1. Frontend CDN or S3 deploy: now VM mostly deals with backend and DB.
  2. Enable Auto or Manual vertical scaling

Chokepoint: Backend & DB — Now is a right time to either use a managed kubernetes service for backend and rds for managed db or we can horizontally scale manually.

Prod Infinite Auto acaling (infinite users, rds and kubernetes auto scaling)

  1. Split DB and backend: Migrate to RDS and kubernetes respectively.

Prod Manual (100x users, manul, backend horizontal scaling)

  1. Split DB and backend to their own VM
  2. Replicate and Load Balance backend VMs.

At this point db vm is the only choke point. backend easily replicates. but db only has one gaint vm.

Prod Manual (1000x users, manual, db horizontal scaling)

  1. DB read replica and DB load balancer

Prod Manual (1000000x users, db sharding, db horizontal scaling, backend horizontal scaling))

  1. Strategic sharding (spliting based on tables, pk range, etc)
  2. backend spliting into microservices
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment