Для SaaS MVP один VPS часто является правильным стартом: web app, database и workers могут жить на одной VM, если backup, monitoring и boundaries продуманы заранее. Много серверов на старте - не scalability.
Сценарий: первые 100 paying users
API/web app, MySQL/PostgreSQL, несколько queue workers и внешний transactional email. Один VPS часто проще и дешевле.
Version 1 architecture
| Компонент | Где |
|---|---|
| Reverse proxy | тот же VPS |
| Application | тот же VPS |
| Database | тот же VPS |
| Workers | тот же VPS |
| Backup | другой failure domain |
Для async-нагрузки смотрите гайд по background workers, для памяти DB - MySQL/PostgreSQL VPS guide.
Четыре trigger роста
- растёт DB RAM/I/O - вынесите DB;
- workers съедают CPU - отделите async;
- растут uploads - продумайте storage;
- растёт web concurrency - добавляйте app node только после исчерпания vertical scaling.
Что нельзя откладывать даже на MVP
- backup/restore test;
- TLS и secrets;
- monitoring;
- rollback;
- migrations;
- transactional email - см. объяснение SMTP.
Платите complexity только за измеримую пользу
Каждый отдельный DB, Redis, worker node или load balancer создаёт operational tax. Если один VPS укладывается в latency и recovery objectives, преждевременное распределение только добавляет failure modes.
Если Linux maintenance мешает разработке продукта, рассмотрите Managed VPS.
Хорошая MVP-инфраструктура маленькая, понятная и не закрывает путь к росту.
