Scaling Decisions: What Breaks First as Your User Base Grows

You’ve launched. Users are signing up. Your MVP is working. Then suddenly something stops working-but probably not what you expected. The difference between building for 100 users and building for 10,000 is rarely about code elegance. It’s about which systems hit their limits first, and whether you’ve thought about that before it becomes an emergency at 2 a.m.

Most founders optimise the wrong things early. They worry about architecture when they should worry about databases. They build beautiful UI while their infrastructure silently approaches collapse. Here’s what actually breaks first, in the order you’ll probably encounter it.

Database Queries and N+1 Problems

This is almost always the first wall you hit. Your app works fine until you’ve got a few thousand active users or tens of thousands of records. Then a page that loaded in 200ms takes 8 seconds.

The culprit? You’re probably fetching related data inefficiently. You load a user, then loop through their records, and inside that loop you fetch metadata for each one. One query becomes 1,000 queries. Your database spends all its time answering questions instead of answering them fast.

The fix isn’t complicated but it requires discipline:

• Use database joins or batch loading instead of loops
• Add caching at the application layer (Redis is standard)
• Profile your queries before they become a crisis-use tools like New Relic or DataDog
• Denormalise data where it makes sense (store calculated values instead of computing them every time)

We see founders waste months trying to optimise application code when the real problem was a missing database index. Run EXPLAIN on your slow queries. You’ll often find the answer in five minutes.

File Storage and Static Asset Delivery

If users upload files-documents, images, videos-you’ll quickly discover that storing them on your server is a terrible idea. Your hard drive fills. Backups get massive. Download speeds get slower because the file is physically far from where users actually are.

Most teams move to S3 or similar cloud storage. That solves storage, but now you need to think about:

1. CDN distribution so users download from a server near them, not from the other side of Australia
2. File access permissions (who’s allowed to download what, and how do you enforce that at scale)
3. Cost-bandwidth bills can surprise you if you’re not monitoring
4. Virus scanning and content validation on upload

The good news: this is a solved problem. CloudFront, Cloudflare, or Bunny CDN will handle most of it. Just don’t assume your basic storage setup scales.

Authentication and Session Management

Your login system works when you have hundreds of users. At thousands, it starts to crack-usually in ways that feel weird and non-obvious.

Sessions get lost. Users get logged out randomly. Some regions experience authentication timeouts. These usually point to one of three problems:

• Sticky sessions-your server is storing session data locally. When you scale to multiple servers, user A hits server 1, their session lives there. They make a request, it hits server 2, which has no record of them. They’re logged out.
• Time synchronisation-if servers have different system clocks, token expiry becomes unpredictable
• Database connection pooling-you’ve run out of available database connections and new login requests queue up

Fix: store sessions in Redis, not in memory. Synchronise your server clocks. Use a proper session store that’s designed for distributed systems. JWT tokens help but aren’t a magic solution-they bring their own trade-offs around revocation and logout.

Payment Processing and Transactional Reliability

If you handle money-and most SaaS products do-you’ll discover that payment systems are unforgiving at scale. A bug that costs you 5 AUD with 50 users costs you 5,000 AUD with 50,000 users.

Common failures:

• Duplicate charges because your idempotency keys aren’t working properly (the same transaction gets processed twice)
• Webhooks from your payment provider failing silently. You don’t record that a customer paid, so you suspend their account
• Race conditions in your billing logic-two processes run simultaneously and both think they’re authorised to charge
• Timezone confusion causing invoices to generate on the wrong date for different customers

You need: proper idempotency tracking, dead-letter queues for failed webhook processing, database transactions that actually enforce ACID properties, and careful testing of edge cases before you go live.

This is one area where cutting corners early becomes expensive later. A fintech we worked with had to issue refunds and manually reconcile accounts for months because they didn’t think through their payment retry logic at launch.

Background Jobs and Asynchronous Work

As you grow, you’ll send more emails, generate more reports, process more data. If you’re doing this synchronously-making users wait while a 30-second job runs-your app feels broken.

You move to a background job queue. But job queues have their own scaling limits. If you’re processing 100 jobs per second and your queue only handles 50 per second, jobs pile up. Old jobs timeout. Newer jobs never run. Your users don’t get their reports for hours.

Solutions:

1. Right-size your queue workers to match your throughput
2. Set sensible timeout and retry limits (don’t retry forever)
3. Monitor queue depth-if jobs are backing up, you need more workers or faster processing
4. Separate job queues by priority (billing jobs run first, analytics jobs run later)

Most teams use something like Sidekiq, Bull, or AWS SQS. The tool matters less than the discipline of monitoring it.

What You Should Do Right Now

You don’t need to solve all of this before you launch. But you should know where your limits are:

• Run load tests before you need them. Find out what 5x your current user count looks like
• Profile your database queries now. Don’t wait until they’re slow in production
• Instrument your app-add proper logging and monitoring from day one
• Document your scaling assumptions (this table will hold 1 million rows, this API endpoint handles 1,000 requests per second)

Most of what breaks isn’t about clever architecture. It’s about understanding where the bottlenecks live, measuring them early, and fixing them before they become crises.

If you’re building a product and want to think through these trade-offs with someone who’s done it before, talk to Amora about your build. We ship MVPs that don’t fall over when they get users.