Systems / 2026 / Live in the browser
Rate Limit Lab
Five rate limiting algorithms replaying the same traffic side by side, plus a node:http middleware that advertises quota with the IETF RateLimit headers.
01
The problem
Rate limiter choices get made from blog diagrams. A fixed window lets a client burst twice the limit across a boundary, and you only see it when the traffic lands right on the edge.
02
How I approached it
Fixed window, sliding log, sliding window counter, token bucket and GCRA all implement one attempt(key, now) interface with the clock passed in, so tests are deterministic and the browser can replay a pattern through all five. A two-pointer sweep over the allowed timestamps finds the densest real window. The sliding counter reproduces Cloudflare's weighted estimate and solves the same inequality for an exact Retry-After. The middleware follows draft-ietf-httpapi-ratelimit-headers-11 and rounds Retry-After up so a client never retries early.
03
The outcome
On edge bursts with a limit of 10 the fixed window lets 20 through inside one window and the other four hold at 10. Zero dependencies, 22 tests including the middleware over real sockets.
Related work
A last-writer-wins CRDT with vector clocks and causal delivery, written from scratch, so three replicas can go offline, edit the same keys and reconverge without a server deciding anything.
A live-stream interactivity bridge: a server and bridge layer that turn viewer actions into real-time events.
A routing simulator implementing and comparing pathfinding strategies under changing network conditions.