Recipe
Capacity Planning
Forecast hardware needs before your user base outruns your infrastructure. This recipe walks through modeling concurrent sessions, memory pressure, and CPU headroom for Meridian deployments.
Step 1 — Define Your Concurrency Model
Start with peak concurrent users, not total accounts. A deployment serving 10,000 registered users typically sees 200–400 concurrent sessions during peak hours. Multiply by your average request rate per session (Meridian profiles average 4–8 requests per second per active session) to get total throughput.
Step 2 — Memory Budget Per Instance
Each Meridian worker process reserves ~180 MB baseline plus ~12 MB per active session context. For 400 concurrent users, budget 5 GB of available RAM across your fleet. Add 30% headroom for GC pauses and burst traffic. Prefer fewer larger instances over many tiny ones to reduce orchestration overhead.
Step 3 — CPU Sizing
Meridian is I/O-bound under normal load; CPU spikes during license validation and Ed25519 signature checks. Provision 2 vCPUs per 100 concurrent sessions as a starting point. Monitor steal time in virtualized environments — anything above 5% warrants dedicated tenancy or a larger instance class.
Step 4 — Network and Disk
Upstash KV lookups add sub-5ms latency in the same region; cross-region reads can spike to 40ms. Colocate your Meridian nodes and KV store in a single AWS or GCP region. Disk I/O is negligible outside of boot — use ephemeral storage and avoid EBS gp2 volumes under 300 IOPS.
Step 5 — Validate with Load Testing
Run a 30-minute soak test at 120% of projected peak before going live. Watch for non-linear latency growth — if p99 crosses 200ms, add instances before the curve bends upward. Meridian's auto-scale hooks respond in ~90 seconds; size your baseline to handle two scaling intervals without degradation.