How would you design a rate limiter for a public API?

Pick the limit dimension first, usually the API key rather than the IP, then choose an algorithm: token bucket to allow bursts, sliding window for smoother enforcement. Keep counters in a shared store like Redis so every instance agrees, using atomic increments with expiry. Return 429 with a Retry After header and remaining quota, and fail open if the limiter itself is unavailable so it cannot take your API down.

I start with what I am limiting per, and for a public API that is the API key, not the IP, because customers behind one NAT should not knock each other out. Then the algorithm. Token bucket is my default, because it lets a client burst a little, which matches how real integrations behave: they wake up, fire twenty requests, then go quiet for an hour. A sliding window log is more precise but stores more per key. The important part is that the counter has to be shared, because if each of my six instances tracks its own count the real limit is six times what I advertised, so Redis with an atomic increment and an expiry, or a small Lua script when I need the check and the decrement together. On rejection I return 429 with Retry After and the remaining quota in headers, because a client that can back off properly stops hammering me. And I fail open, since a limiter that takes the API down has done more harm than the abuse it prevented.