Why Great Systems Say "No" More Often Than You Think

(Rate Limiting Explained)

One idea completely changed how I think about scalable systems. The best systems aren't the ones that accept every request. They're the ones that know when to say "No."

That sounds backwards. Isn't the whole point of software to serve users?

Yes. But imagine your application suddenly receives 10 million requests. Should it process all of them?

If it tries...

• The API becomes overloaded.
• The database struggles to keep up.
• Response times increase.
• Retries begin.

Soon, even legitimate users can't complete simple actions.

The system didn't fail because it rejected requests. It failed because it accepted too many.

That's why internet-scale platforms use rate limiting.

Instead of saying yes to everything, they make intelligent decisions.

• Limit requests from a single client.
• Protect critical endpoints like login and payments.
• Slow down abusive traffic.
• Preserve capacity for legitimate users.

This isn't about restricting users. It's about protecting the experience for everyone.

One lesson that's stayed with me throughout my career is this: Availability isn't measured by how many requests you accept. It's measured by how many users you continue serving when traffic explodes.

The next time you see: 429 — Too Many Requests

Don't think of it as an error. Think of it as the system making a difficult — but necessary — architectural decision.

Because sometimes... The most reliable systems are the ones that aren't afraid to say "No."

Have you ever worked on a system where rejecting some requests actually improved reliability?