Asked about The coding round where the spec keeps changing

Design a rate limiter that supports several limits per user at once.

An answer that works

Keep one allow(key) entry point and key the state by key and rule. Check every rule before consuming any budget, so a call rejected by the hourly rule does not spend the per-second one. That all-or-nothing pass is the part that has a bug in most implementations.

Then they push further

Now make it safe under concurrent callers.

The read-check-write inside allow is the race, so the lock goes around the whole of it rather than around each dictionary access. If the state moves out of process, the same operation has to become atomic in the store instead, which is why it was worth keeping in one method.

Reading an answer is not being able to give one. The section that teaches this is The coding round where the spec keeps changing, 4 hours of Interviewing well.

Learn this properly