The Runtime Theory
easyleetcode#hash-map#stateful-service

Implement a Time-Based Logger Rate Limiter

Track the last accepted timestamp for each message and reason about state growth, ordering, and concurrent requests.

The Runtime Theory Team1 min read
Solve it

Solving happens on the judge — come back and mark it done

Sample cases

in(1,foo),(2,bar),(3,foo),(8,foo),(10,foo)

outtrue,true,false,false,true

insame message at timestamps 5 and 15

outBoth accepted when the rule requires at least 10 seconds between accepted occurrences

Implement a service that accepts a message only when at least ten seconds have elapsed since the last accepted occurrence of that same message. Different messages have independent histories.

Store the last accepted timestamp for each message. Rejected requests must not move the timestamp forward, or repeated attempts can postpone acceptance forever. State the behavior at exactly the ten-second boundary.

For a production service, add questions the coding exercise leaves open: do requests arrive out of order, is state shared across replicas, how is old state expired, and what happens during a restart? The linked challenge covers the in-memory core, not a distributed rate-limit contract.

One dispatch a week

The trace behind each problem, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save