A strong answer. “First, is 50k peak or average? I'll assume average and apply a three-times peak factor, so 150k at peak — tell me if that's wrong for your traffic.

Then per-node capacity. For a simple stateless service I'd assume a few thousand requests per second at seventy percent CPU — call it 3k, which I'd want to measure rather than guess. That's 50 nodes to serve peak. Then failure domains: three availability zones, each able to carry the load with one zone gone, so about 75. Then 1.4× for growth and because autoscaling isn't instant. Call it 105 nodes.

But the interesting part is that CPU is almost never the binding constraint. Here I'd expect it to be the datastore — connection limits, or write throughput. Little's Law says at 150k requests per second and 200ms latency I have 30,000 requests in flight, which tells me the connection pool and the memory footprint immediately, and it's usually where this design actually fails.

And 99.9% is about 43 minutes of error budget a month, which means one bad deploy consumes most of the quarter. So I'd want staged rollout with an automatic halt condition before I'd want any of the scaling machinery.”