When clients send a bit too many requests, unprotected servers can get overloaded. Rate limiting is the method by which servers protect themselves from this. There are a couple canon strategies for it, and hey, they somewhat reminded me of strategies that people with money use to avoid becoming people with not as much money.
Let's dig into that.
Fixed Window
The simplest rate limiting strategy. Allow up to N requests per time window, usually per client. If you used this for budgeting, maybe you'd tell yourself to only spend $X per month on each of a number of discretionary expenses, from eating out to gifts. This does work just fine. The only issue is it lets you splurge quite a lot at window boundaries in some cases, but that's a tradeoff that may be worth it for your scenario.
Sliding Window
Sliding window adds memory overhead to fixed window to get rid of the window boundary edge case. For budgeting with a sliding window, you'd need to keep track of the days you made each and every purchase so you can know when they are no longer part of the current window.
Token Bucket
Imagine at set intervals, you got some small amount of dollars added to your budget, up to a maximum 'bucket size'. If you find that you eat up your budget in a window as soon as you can and aren't able to pace yourself, using 'tokens' like in the token bucket strategy helps you even out your purchases and incentivize fewer undesired financial decisions. Bursts of spending are supported yet controlled.
Leaky Bucket
Leaky bucket is like the token bucket, except the bucket can only be drained at a fixed rate. This often means you need to have a very smooth expenditure. Purchases can range from buying a stick of string cheese to buying a four-bedroom, five-bathroom house, so enforcing smoothness doesn't strictly work. If you limit buckets to the type of discretionary expenses you can realistically make smooth, such as food & drink, the leaky bucket can be more doable.
Adaptive limiting
In rate limiting terms, this means dynamically adjust limits using latency, error rate, or system load to prevent overload. In budgeting terms, this might end up meaning you only stop spending when your total liquid cash drops below a certain amount. So instead of having an upper limit on spend, you have a sort of lower limit on wealth.