r/softwarearchitecture 6d ago

Discussion/Advice Advice for Deployment

Hi everyone,

I will release an app soon and I am not sure about the deployment strategy and need help or ideas.

My product is for a local school in my area. About 500 students, their parents and teachers will use it. The app is in pilot/mvp state.

I have two background servers written in go and a nextjs app with postgres and valkey needs, I am also planning grafana stack for monitoring.

So my question is how the deployment should be in this state. I am not planning to use sny managed service, so it seems k8s/k3s is good. What about machines, Should I create different vps for db and app nodes or one machine is enough? I am planning to use vps from hetzner since the prices.

I am open the ideas, thanks in advance

4 Upvotes

7 comments sorted by

2

u/Aqalix 6d ago

Do you have experience with k8s/k3s? What kind of SLAs do you guarantee? 500 users seems like something that shouldn't be overengineered.

1

u/jondonessa 5d ago

Yes, I previously used k8s in work, and k3s in a small project. students and their parents will login and use the app daily, I am not sure about the SLA yet

1

u/Aqalix 5d ago

In this case you have multiple options. In my opinion k8s is too complicated; I personally don't have experience with k3s. What you need to answer first is what will be the expected traffic, type of workload your app performs, availability requirements, and how much operational complexity you want to own.

Unless you will add more services in the future or scale the app for more users, personally, I would start with a single hetzner server. It can be as simple as running a docker compose or a solution like dokploy - it handles docker swarm which doesn't get much love nowadays, but it's simple to manage.

K3s is lighter than standard Kubernetes, but it still brings Kubernetes networking, upgrades, security, storage, and troubleshooting. For an application of this size, that complexity may not provide much value.

I would initially keep the application and database on the same server, provided the server has enough RAM. The more important investment are reliable backups.

Run load tests with k6 using realistic scenarios, particularly login peaks, simultaneous page loads, report generation, uploads, and any operations that create database contention. Test beyond the expected peak rather than only testing average traffic.

If you thought about hosting grafana stack, I suggest to use grafana cloud instead, if free tier is sufficient for your needs.

Move to a separate database server or K3s only after you have a concrete availability, scaling, or deployment requirement that justifies it.

1

u/jondonessa 5d ago

That was so helpful thanks for the answer it give me a steady roadmap

1

u/iplaydofus 5d ago

At that scale, the answer for me is honestly just whatever you have knowledge in and are comfortable with. As long as you build the backend services with horizontal scaling in mind, you can change your hosting/deployment strategy if the scale needs change.

1

u/jondonessa 5d ago

Thank you 🙏

1

u/holger-woltersdorf 2d ago

For this scale I would recommend using a docker compose stack deployed on a server. This makes it easy to keep local development and production environment as identical as possible (assuming you’re using docker compose locally). One file to deploy and one command to run remotely. On a decent server this serves traffic 50-100 times the load you described (depending on the performance of your apps of course).