Start with one server; monitor and scale vertically until you hit limits or cost. Then add more nodes and load balancing. Separate DB and app tiers; use caching and async queues. Plan for stateless app servers to scale horizontally.
Single server phase
- One box: App, DB, and cache on the same machine. Simple and cheap for low traffic.
- Monitor: CPU, memory, disk I/O, and bandwidth. When utilization is consistently high or you hit limits, plan to scale.
- Vertical first: Upgrade to more CPU, RAM, or better disk before adding more servers. Often the fastest win.
Add tiers and horizontal scale
- Separate DB: Move database to its own server (or managed service). App servers connect to it. DB can be scaled independently (replicas, bigger instance).
- Multiple app servers: Put two or more app servers behind a load balancer. Requires stateless app or shared session store (Redis, DB).
- Caching: Redis or Memcached for session and response cache; reduces DB load and speeds up responses.
- Async queues: Offload slow or batch work to workers (email, reports, imports). Keeps the request path fast and lets you scale workers separately.
Stateless and automation
- Stateless app: No local session or file state that ties a user to one server. Enables horizontal scaling and easy replacement of nodes.
- Automation: Use config management and CI/CD so adding a new app server is repeatable and quick. Auto-scaling groups if your provider supports them.
Summary
Start single server; scale vertically then add DB tier and multiple app servers behind a load balancer. Use cache and queues; keep app servers stateless. Automate so scaling is repeatable.
