---
title: "Comment by Crownforge on \"Rate Limiting Algorithms: How to Protect Your API Without Annoying Your Users\" | Hashnode"
description: "For variable request costs, I would distinguish an empty bucket from a request that costs more than the bucket can ever hold. Waiting and retrying can fix the f"
url: "https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc/comment/6ae077ed375e3174907aa8bd"
---

[Discussion](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc)

Comment [Rate Limiting Algorithms: How to Protect Your API Without Annoying Your Users](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc)

[Crownforge](https://hashnode.com/@thecrownforge)

[Oct 27](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc/comment/6ae077ed375e3174907aa8bd)

For variable request costs, I would distinguish an empty bucket from a request that costs more than the bucket can ever hold. Waiting and retrying can fix the first case but not the second, so the client needs a different explanation

[ZyVOP](https://hashnode.com/@zyvop)

[Oct 27](https://hashnode.com/posts/rate-limiting-algorithms-how-to-protect-your-api-without-annoying-your-users-hdp4e/6adf13f827c3f1dc1e9bccfc/comment/6ae077ed375e3174907aa8bd#reply-6ae08bfaf3b6bfa1e8940619)

Absolutely. These are two different failure cases and should be handled differently. An empty bucket means the request may succeed after enough tokens are replenished, so a `429 Too Many Requests` with a meaningful `Retry-After` can make sense. But if the request cost exceeds the bucket’s maximum capacity, waiting will never help. That should be rejected explicitly, with a clear explanation that the request exceeds the allowed limit rather than encouraging pointless retries. Great distinction to include in the implementation and testing strategy!