Oddly, they have no problem shutting things off when the limits of their free plan are exceeded:

https://firebase.google.com/docs/projects/billing/firebase-p...

I am not sure how they can do that, but cannot let people set their own limits on their paid plans.

How is the service being able to answer the question "is there budget available for this action?" different from "is there authorization for this action?"

> cause outages

That's fine. The major LLM providers work like this. If you're out of credit, or hit your monthly recharge limit, it stops working, bringing down prod with it if your product relies on it. Not heard anyone complain about the concept.

If it's really a problem for you, you can be all enterprisey and contact sales, then they'll be very excited to offer you extremely high limits and post billing.

This way everyone gets what they wants.

You solve this by opt in, not fancy engineering. There are two classes of customers - those that absolutely can't afford services be cut, and those that absolutely can't afford a 50k bill.

So you deploy an advanced technology known as a radio button to toggle which they want, throw a bunch of ToS & consent agreements about data loss / deletion at the ones opting for hardcaps....and done.

Also reminder that Azure has hard caps for certain account types. This is not a technical problem. They can do this, they just don't want to.

> It's easy to build a bad billing cap that would slow down services and cause outages

When you've exhausted your billing cap, what else could it do? Either shutting off services or blowing past the cap seem like the only serious options.

For a lot of small businesses, I suspect that an outage is often better than risking a surprise 6 figure bill. But it depends on what your software does.

Also if the system shut down automatically when the budget got exhausted, there's a risk that a runaway backup process or something might accidentally eat through your regular budget and get the site shut down. For that, it might make sense to assign different resources into different budgetary buckets or something.

I'm surprised firebase doesn't implement something like that.

I am sitting on an algorithm for hard billing caps right now that seems it may have some holes, but gets close based on several very tricky distributed systems problems. Making a billing cap that doesn't amount to "just use one single gateway server" (serializing everything and introducing tons of latency) seems to be harder than building a database or a filesystem, and most programmers would never attempt even those.

> it's basically impossible to build a good billing cap.

They don't have a problem implementing caps on a free tier. No one's asking for perfect, but they don't seem to care about even getting to the ballpark.

Seems pretty similar to distributed rate limiting. But it's much simpler to solve the common case of overspending on a single API: give each API the same daily limit with no communication between APIs.

Either you want automatic scalability or you want caps. Scalability is hard with caps. Say your site selling stuff sees spike and scales up and hits cap, should the service degrade in way you did not plan for? Or go past the cap as you are still making money?