◇ Could this help me?
Yes. The explanation is technically correct, including the boundary burst in fixed window counters, the continuous refill of the token bucket, and the need for shared state once traffic is spread across servers. The framing of a rate limit as burst size plus refill rate rather than a single number is the takeaway worth keeping, because it is what makes limits predictable for real users. This is a general practice.
Review how rate limiting works in this project. Tell me whether it is a fixed window counter, a token bucket, or something else, and whether the state is per process or in a shared store. Then propose a token bucket implementation that stores only the current token count and last-updated timestamp per user, calculates refill from that timestamp, and works correctly across multiple instances. State the burst size and refill rate you recommend for each endpoint and why.