Hacker News new | ask | show | jobs
by donavanm 660 days ago
I dont understand what youre on about. The post I replied to, and many others, use “caps” to refer to limits of service based on billing. This is an endless source of comments on every “cloud” topic. I provided a very brief overview of why large billing systems are more complicated than expected and have an impedance mismatch to the stated desire. But sure, tautological brain rot. Got it. Im sure you have a wealth of experience with metering, billing, and pricing for billion dollar revenue streams.

Now if you have some _other_ proposal for how billing and service limits could function Im legitimately interested. But I dont see anything at all specific or actionable in your replies. Insurance is interesting for _some_ facets. Im curious how you think that aligns with dynamic resource utilization and what happens at the boundary.
1 comments
Dylan16807 660 days ago
> if you have some _other_ proposal for how billing and service limits could function Im legitimately interested.

Billing doesn't have to be so complicated you can't calculate it in less than a minute. That's a technical failure. Surely you can imagine a better way? If you really think it can't be better, then it's hard to argue against "brain rot".

Also on most systems it will work perfectly fine to use an estimate of the price per unit when calculating the bill for the last couple hours.

link
donavanm 659 days ago
Again, unless you have domain expertise I suspect you are drastically underestimating the complexity of reality. As I alluded to earlier metering, pricing, and billing are _at least_ three separate complicated problems in substantial systems. There are multiple metering dimensions that interact with each other, time, and periodicity at a minimum. Saying “do billing better” without either a thorough understanding of the existing system, or an actual concrete proposal, is not useful.
link
Dylan16807 659 days ago
Being separate systems is fine as long as they can all calculate a number within the time it takes to make a cup of coffee. That's not hard if you actually make it a design goal.

I'm sorry that "prioritize it" isn't very helpful, but it's true. If the calculation takes longer than that, it's a management-induced problem.

If we're positing a system that can already do that, then you need to be more specific about the problem you're describing because it's not obvious.

link