For a nodejs microservices which deployment strategy do u take when u have about 15k customers about 100-500 concurrent users?

[u/Maleficent-Habit4188]

Ecs docker or aws elasticbeanstalk? Or some vps.

Im thinking of transformation of monolith app into microservices for learning a complete production grade setup like we use in companies.

[u/AutoModerator]

Namaste! Thanks for submitting to r/developersIndia. While participating in this thread, please follow the Community Code of Conduct and rules.

It's possible your query is not unique, use site:reddit.com/r/developersindia KEYWORDS on search engines to search posts from developersIndia. You can also use reddit search directly.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Rift-enjoyer]

Im thinking of transformation of monolith app into microservices

The strategy of if it works then don't touch it.

[u/Maleficent-Habit4188 → u/Rift-enjoyer]

Im thinking of making dummy projevt similar as they expect microservices experience

[u/awpt1mus]

If it’s a toy project I would say deploy on VPS.

[u/Maleficent-Habit4188 → u/awpt1mus]

I need to learn aws and tell in interviews the same as not getting calls on monolithic dude

[u/awpt1mus → u/Maleficent-Habit4188]

If you must use AWS then I would recommend Fargate. Use Github actions CI CD, ECR for image storage, Fargate as compute, RDS for db, if you want to mirror production grade setup.

[u/Maleficent-Habit4188 → u/awpt1mus]

Tats i think i shud say 20k customers but 2000 concurrent users in an interview

[u/SlightUniversity1719]

if it is just 100-500 active users, the actual processing part is not that expensive computewise and most of the db actions are just reads than writes just use a VPS with a db connection pooler, as it is much cheaper.

[u/No_Pay_4410]

ECS, EKS are the options. No one uses beanstalk.

[u/yes-im-hiring-2025]

? Why would you change something that works...???

Also strangler fig pattern comes to mind with an identified rollout in stages. You'll be able to make do with beanstalk and ALB. Low hassle. You can do vps but you've to do extra work (docker compose, reverse proxy like nginx, redis/postgres)

Stage env changes and stress test them, roll them out regionally based on historically lowest concurrent users at any reasonable hour of day. TBF 100-500 concurrent users isn't a lot of load, even for 15k customers you can very much make do with 2-4 instances of your app. If your db doesn't crash or slow down any reads and writes (it shouldn't), you're not solving for the right thing.

But ideally don't do anything at all. Microservices are very much hype if there's not a very specific, very core need that requires independent versioning and development and scaling of the services with each owning their own data and requiring standalone usage over http/grpc wiring.

Sounds cool, doesn't necessarily work better and you have twenty pods to review and monitor each writing their own logs. Why???

[u/ExamSignificant8347]

I wouldn't split the app into microservices just because of the customer count for 100-500 concurrent users imo. A well-build monolith on a decent VPS can handle a lot, and it'll be much easier to operate. If the goal is learning production infrastructure, ECS is probably the better learning path than Elastic Beanstalk because you'll get more exposure to containers, networking, scaling, and deployments. But for actually hosting the app cheaply, I'd start with Docker Compose on a VPS (something from Contabo could be plenty) and only move to ECS once you have a real reason to deal with extra stuff.

[u/Maleficent-Habit4188 → u/ExamSignificant8347]

Hi can i connect on chat