Para un SaaS MVP, un solo VPS suele ser un buen punto de partida: web app, database y workers pueden convivir si backup, monitoring y boundaries están bien definidos. Comprar muchos servidores desde el primer día no es scalability.
Escenario: los primeros 100 paying users
API/web app, MySQL/PostgreSQL, algunos queue workers y transactional email externo. Un VPS suele ser económico y fácil de depurar.
Version 1 architecture
| Componente | Ubicación |
|---|---|
| Reverse proxy | mismo VPS |
| Application | mismo VPS |
| Database | mismo VPS |
| Workers | mismo VPS |
| Backup | otro failure domain |
Para async workload consulta la guía de background workers; para memoria DB, la guía MySQL/PostgreSQL en VPS.
Cuatro triggers de crecimiento
- sube RAM/I/O de DB - separa la base;
- workers consumen CPU - separa async;
- crecen uploads - diseña storage;
- crece web concurrency - añade otro app node solo cuando vertical scaling deje de ser suficiente.
Lo que no debes posponer por ser MVP
- backup/restore test;
- TLS y secrets;
- monitoring;
- rollback;
- migrations;
- transactional email - revisa la explicación de SMTP.
Paga por complexity solo cuando aporte valor medible
DB separado, Redis, load balancer y workers extra crean operational tax. Si un VPS cumple latency y recovery objectives, distribuir demasiado pronto añade failure modes.
Si Linux maintenance distrae al equipo de producto, Managed VPS puede ser práctico.
Una buena infraestructura MVP es pequeña, comprensible y deja salidas claras para crecer.
