API sunucusunda toplam kullanıcı sayısı yerine saniyedeki istek, payload boyutu, database sorgu maliyeti ve eş zamanlı bağlantı önemlidir. Trafik profili ölçülmeden CPU/RAM seçmek aşırı veya yetersiz kaynak tahsisine yol açabilir.
Peak RPS, p50/p95/p99 latency, hata oranı, timeout, database query süresi, connection pool, CPU, RAM ve queue lag temel metriklerdir. Webhook servislerinde retry ve idempotency ayrıca izlenmelidir.
TLS termination, rate limit ve request loglama uygulama process'inden önce edge/reverse proxy katmanında yönetilebilir.
RPS tek başına yeterli değildir; ağır database sorgulu 50 RPS, cache'li 500 RPS'den daha pahalı olabilir.
Authentication, authorization, rate limit, schema validation, secret yönetimi ve audit log birlikte ele alınmalıdır.
Uygulama APM yanında host seviyesinde socket ve kaynak görünümü alın.
ss -sss -lntpuptimefree -hps aux --sort=-%cpu | headjournalctl -p warning --since '-15 min'Önce app'i stateless hale getirmek, ardından load balancer arkasında ikinci instance eklemek genellikle en temiz yoldur.
Peak RPS, request başına CPU süresi ve database maliyetine göre değişir. Load test olmadan sabit vCPU önerisi güvenilir değildir.
Zorunlu değildir ancak TLS termination, buffering, rate limit ve access log gibi görevler için reverse proxy faydalıdır.
Ağır işi request süresinden ayırmak retry ve dayanıklılık açısından faydalıdır.
Peak RPS, framework, database, payload ve timeout bilgilerini iletin; uygun VPS/VDS topolojisini çıkaralım.