Proč je scalabilita kritická
Pokud kupujete SaaS s plánem růstu, aplikace musí zvládnout 10–100× více uživatelů. SaaS, který se škáluje lineárně (2× uživatelů = 2× náklady), má nižší hodnotu než ten s ekonomikou z rozsahu.
Typy škálovatelnosti
1. Vertikální (scale up)
Silnější server = více výkonu. Jednoduché, ale limitované:
- Přidáte RAM, CPU, disk
- Funguje do určitého bodu
- Single point of failure
2. Horizontální (scale out)
Více serverů = více výkonu. Preferovaný přístup:
- Load balancer rozděluje zátěž
- Stateless architektura
- Auto-scaling
Jak ověřit scalabilitu
1. Architektonická analýza
| Otázka | Dobrá odpověď | Špatná odpověď |
|---|---|---|
| Stateless/Stateful? | Stateless (session v Redis) | Stateful (session v paměti) |
| Databáze? | Read replicas, sharding ready | Single instance, no replication |
| Cache? | Redis/Memcached | Žádný cache |
| CDN? | CloudFront/Cloudflare | Vše z jednoho serveru |
| Queue? | RabbitMQ/SQS pro async jobs | Synchronní zpracování |
2. Load testing
Proveďte zátěžové testy s nástroji:
- k6 — moderní load testing tool
- Apache JMeter — Java-based, komplexní
- Locust — Python, scriptovatelný
- Artillery — Node.js, cloud-native
Co testovat
- Concurrent users — kolik současných uživatelů zvládne?
- Response time — degraduje s počtem uživatelů?
- Error rate — začnou padat requesty?
- Database performance — bottleneck v DB queries?
Nákladová škálovatelnost
Nejen technická, ale i finanční škálovatelnost:
| Scénář | Náklady na infra / uživatel | Hodnocení |
|---|---|---|
| Klesající (economies of scale) | 10× uživatelů = 3× náklady | ✅ Výborné |
| Lineární | 10× uživatelů = 10× náklady | ⚠ Akceptovatelné |
| Rostoucí (diseconomies) | 10× uživatelů = 20× náklady | ❌ Problém |
Jak to vypočítat
- Zjistěte aktuální cloud bill a počet uživatelů
- Vymodelujte náklady při 2×, 5×, 10× uživatelů
- Porovnejte s projected revenue
- Gross margin by měla zůstat nad 70 %
Červené vlajky
- Monolith bez možnosti horizontální škálování
- N+1 query problémy v databázi
- Žádný caching
- Synchronní zpracování dlouhých operací
- Single database bez read replik
- Manual deployment → nemůžete rychle škálovat