Rate limiting is everywhere in the API world, but most teams implement it badly. In this episode, Lucas and Luna dig into how the API team at Stripe, a payments company, approaches rate limiting for their public API. They break down why the classic token bucket algorithm creates a 'burst then cliff' experience, how Stripe's approach uses a leaky bucket with a rolling window to smooth out traffic, and what the '429 Too Many Requests' response actually means for the client. They also discuss the importance of the Retry-After header, the trade-off between strict limits and customer empathy, and why a little chaos engineering goes a long way. The hosts explain how to design rate limits that protect your infrastructure without punishing your best customers, and share concrete numbers from Stripe's developer docs. If you've ever hit a 429 and wondered what went wrong, or if you're designing an API that might one day be popular, this episode will change how you think about rate limiting.