Ten thousand registered users and ten thousand concurrent users require very different capacity. SaaS sizing should combine peak concurrency, request rate, database working set, background jobs and file volume.
Yes. A low/mid-scale SaaS can start with app, Redis and database on one NVMe VPS. Separate services as p95 latency, DB IO, queue lag or deployment impact grow. Moving to Kubernetes without measurements can add unnecessary operational load.
Separating web/API requests, cache/session, database and background workers creates cleaner operational and scaling boundaries.
Monthly active users are a business metric; concurrency and request profiles are more direct infrastructure signals.
Tenant filters, authorization, database policies and audit logging should reinforce each other. Cross-tenant data exposure is a critical breach.
Combine application APM with host load, memory, IO and connection trends.
uptimefree -hvmstat 1 10iostat -xz 1 5ss -sdf -hEvery system differs; the real bottleneck should determine the order.
No. Docker Compose or a simple multi-VPS design can be enough for many low/mid-scale SaaS systems.
There is no single answer. Measure peak concurrency, per-request memory, database and queue load.
No. It can help with sessions, cache and queues; memory budget should be planned separately.
Share peak users, RPS, DB size, queues and files; we can design from one VPS to a scaled topology.