Design the scale path, not a million-user bill

I do not sell you a million-user architecture. I sell you judgment about what to build now, what to leave as a seam, and what to ignore. A lead solutions architect who starts with EKS, a global database, and a second region is answering a brief you should have rewritten. The job is to get you to the next real traffic step without paying for the last one.

Diagnosis before a single AWS service

I do not open the service catalog first. I start with what is breaking, and why. That is the same diagnosis before build sequence I use on every engagement. Listen, map the symptoms, name the root cause, then rank the fixes.

What I ask in the first hour

1. Peak requests per second on the hottest endpoint, not the user count in the deck. I explained why that number is the wrong starting point in one million concurrent users is the wrong number.
2. Which calls are synchronous, and which can wait.
3. Which data store cannot scale horizontally today.
4. How you know you are down, and who gets the page.

What I refuse to do

I will not turn a fear of a spike into a platform rebuild. If the honest read is that you need SaaS production readiness more than a migration, I say that. If the quote you already have is sized for a crowd you do not have, I mark the cuts. That is the costly AWS mistake I will not repeat.

Measure the real bottleneck, then pick the service

Capacity problems have a location. Find it before you pick Lambda, Fargate, or a bigger database.

Scope, difference, evidence

When a path is slow or falling over, I treat it like an incident.

1. Scope. Which endpoint or tenant fails, and what still works.
2. Difference. What separates the failing case from a healthy one.
3. Evidence. The exact log, latency trace, connection count, or lock that supports the claim.
4. Verification. The change that fixes the failing case without breaking the ones that already work.

Then choose the boring service

Most startups need a managed multi-AZ default, not a custom platform. API Gateway in front of Lambda or ECS Fargate. RDS or Aurora for relational data you already have. SQS in front of writes that can wait. DynamoDB when the access pattern is simple and the key is honest. The AWS Well-Architected Reliability design principles say to "stop guessing capacity." Measure, then let the service grow.

Fix shape before you add capacity

More hosts on a bad shape waste money. I fix the shape first. That is the same rule I used on a 100+ Lambda production platform. The New York Lottery apps did not need more concurrency. They needed domain boundaries, smaller packages, and IAM that matched the function.

What shape work looks like

1. Split the hot path from the slow path so a report job cannot sit on the request path.
2. Put a queue in front of any write that the user does not need in the same second.
3. Cache the read that every session asks for.
4. Give each domain its own deploy, so one release cannot take the site down.

What I do not tune yet

Provisioned concurrency, huge instance classes, and multi-region replicas come after the path is honest. I wrote about the latency side of that trade in taming Lambda cold starts. Tuning knobs on a tangled backend is how you buy a month of relief and keep the same outage.

Leave seams you can open later

A scale path is a written sequence, not a pile of unused infrastructure. You should know what you run at today's peak, what changes at the next order of magnitude, and what signal tells you to spend.

A path I will put on paper

1. Now. Single region, multi-AZ managed services, health checks, and alarms a human reads. I covered that floor in how to meet a 98% uptime SLA.
2. Next. Split the first hot domain, add a queue, and raise Auto Scaling limits you already tested.
3. Later. Read replicas, caching, or a second data store when a specific query or tenant forces it.
4. Much later. A second region, and only after you have run a failover you can repeat.

Werner Vogels, Amazon's CTO, put the constraint in one sentence. "Everything fails, all the time." You design for that with seams and recovery, not with a larger bill. AWS repeats the line in its architecture guidance.

The trigger to spend more

Each step needs a number. Peak RPS, p99 latency, error rate, or connection pool saturation. When the number appears, we open the next seam. Until then the extra service stays off the invoice.

Prove it with a load test you can repeat

A scale path you have never run is a guess. I want a test you can fire again after every serious change.

What the test has to include

Drive the real hot path, not a health check. Include the database and the queue. Raise load in steps. Watch the first resource that bends. AWS publishes a Distributed Load Testing on AWS pattern if you want the harness in your account. The tool matters less than the habit.

What I do with the result

If the test dies on a single writer, we change the shape. If it dies on a limit we already planned to raise, we raise it. If it holds past the next traffic step, we stop spending. That is the output of an architecture audit: a ranked list of what to change, and a shorter list of what to leave alone.

Frequently asked questions

How is this different from a typical lead solutions architect pitch?

I do not start with a service list. I start with the load you have, the path that fails first, and the three things I will not build yet.

What do you actually build in the first thirty days?

A managed single-region baseline, the first bottleneck fix, alarms that reach a person, and a written scale path with triggers. Not a million-user replica.

When do you add Kubernetes or a second region?

When the numbers on the path say the current shape is the constraint, and the team can operate the new one. Not because a deck asked for 1 million concurrent users.

How do you prove the app will survive a spike?

A repeatable load test on the hot path, plus health checks and alarms you already trust. A larger diagram does not prove it.

What do you need from me to start?

The architecture diagram, last month's peak traffic, and the current bill or quote. I will tell you the first three things I would change, and the first three I would not.

Do you take greenfield apps with no users yet?

No. Structure problems need something to structure. This work is for teams who have traffic, or a real launch date, and are about to overbuy the ending.