For API servers, requests per second, payload size, database query cost and concurrent connections matter more than total users. Sizing CPU and memory without traffic measurements can over- or under-provision resources.
Peak RPS, p50/p95/p99 latency, error rate, timeouts, database query time, connection pools, CPU, memory and queue lag are core metrics. Webhook systems should also track retries and idempotency.
TLS termination, rate limiting and request logging can be handled at the edge/reverse proxy before the application process.
RPS alone is insufficient; 50 RPS with expensive DB queries can cost more than 500 cached RPS.
Authentication, authorization, rate limits, schema validation, secrets and audit logs should work together.
Combine application APM with host-level socket and resource visibility.
ss -sss -lntpuptimefree -hps aux --sort=-%cpu | headjournalctl -p warning --since '-15 min'Making the app stateless before adding a second instance behind a load balancer is usually the cleanest path.
It depends on peak RPS, CPU time per request and database cost. A fixed number without load testing is unreliable.
Not mandatory, but a reverse proxy is useful for TLS termination, buffering, rate limiting and access logs.
Separating heavy work from the request path improves retries and resilience.
Share peak RPS, framework, database, payload and timeout profile; we can design the VPS/VDS topology.