# Exercise 1: Design Auto Scaling for an API and a Worker Fleet

## Facts

- `api` (Node, EC2 behind an ALB): one `c7g.large` handles ~900 req/s at 60% CPU before latency degrades; boot + warm-up = 3.5 minutes. Traffic: 2,000 req/s overnight, 9,000 req/s daily peak at 12:00–13:00, ramping from 11:30. Black Friday: up to 25,000 req/s.
- `worker` (EC2, consumes SQS): each instance processes 40 msg/s. Messages must be processed within 5 minutes of arrival. Normal inflow 200 msg/s; bursts of 3,000 msg/s for 10 minutes after marketing emails.
- PostgreSQL (RDS) allows 800 connections; each api instance opens a pool of 20, each worker 10.

## Deliverables

1. **api ASG**: min/max/desired, AZ spread, health-check type and grace period, scaling policy (metric + target value). Show the math for the target value.
2. **Peak preparation**: how will the fleet be ready for the 11:30 ramp given the 3.5-minute boot time? (scheduled, predictive, warm pools, headroom — choose and justify.)
3. **worker scaling**: define the "backlog per instance" metric (metric math) and its target so the 5-minute SLA holds; compute the instance count needed during a 3,000 msg/s burst.
4. **Database limit**: with your max sizes, do you exceed 800 connections? If so, propose two solutions.
5. **Black Friday**: what changes (quotas, pre-scaling, load test plan, CloudFront)?
6. **Alarms**: list the 5 alarms you'd configure for this system (metric, threshold, action) — at least two must be symptom-based.

## Requirements Checklist

- [ ] api target: `ALBRequestCountPerTarget` ≈ 750–900 (or CPU ~50–60%) with reasoning from the 900 req/s capacity; ELB health checks, grace ≥ warm-up time; min ≥ 3 across 3 AZs.
- [ ] Peak handled by scheduled scaling (raise min before 11:30) and/or predictive scaling/warm pools, explicitly because reactive scaling lags 3.5+ minutes.
- [ ] Worker metric: `ApproximateNumberOfMessagesVisible / RunningCapacity` with target = 40 msg/s × acceptable latency (e.g. 40 × 300 s = 12,000 max, choose a safer target such as 2,400 for ~1 minute of backlog); burst needs ≈ 3,000 / 40 = 75 instances for real-time processing (or fewer if the backlog may drain within 5 minutes — show the trade-off).
- [ ] Connection math done (e.g. 30 api × 20 + 75 workers × 10 = 1,350 > 800) with solutions: RDS Proxy, smaller pools, cap max sizes, queue-buffer worker writes.
- [ ] Black Friday: raise service quotas (EC2 vCPUs), pre-scale, load test, cache at CloudFront.
- [ ] Alarms include 5xx ratio and p99 latency (symptoms), queue age, DLQ depth, DB connections/CPU, scaling failures.