Design a Rate Limiter

"Design a rate limiter" is a small prompt with a lot of edges, which is exactly why a JPMorgan panel reaches for it. There is barely any architecture to draw. There is one component that sits in front of a service, counts how many requests a caller has made in a window, and returns a yes or a no. The component has to be correct under concurrent requests and cheap enough to run on every call. It also has to be clear about its counting rule, since each rule trades burst tolerance against accuracy differently. Pick the algorithm that fits the requirement and defend it, keep the counter correct when many requests hit at once, and the design is done. Reach for a plain counter with no thought about the window boundary or the race, and it reads like you have never run one in production.

This is the component-level shape the JPMorgan overview names but never works through, and it is a clean test because every layer of the skill shows up honestly. There is algorithm reasoning, because a token bucket and a fixed window answer the same question with different burst behavior, and knowing which to pick is graded. There is concurrency: the check-then-act at the center of a limiter is the classic race. A limiter that lets two requests read the same count and both pass is worse than useless. There is the distributed step. A bank runs many instances of a service behind a load balancer, so a counter in one process's memory is wrong once the fleet has two nodes. And there is configuration, because a real limiter has a different budget for a premium client than for an anonymous one. Reason through all of that and you sound like you have built middleware. One who writes a single counter and calls it done has not.

The JPMorgan angle

JPMorgan's backend is enterprise Java behind an API gateway, so a rate limiter is production middleware the bank ships. The gateway in front of a payments API or an internal service is the natural home for one. J.P.