PulseHTTP

The request path of an HTTP/1.1 server, drawn as a transit line. Every train is a request through the real route table.
Service status
Good service on all lines
request line, outbound response line, returning cache loop, a short turn train in flight held at the block, 429 no entry, 401 or 403 levers: drag, or arrow keys

What you are looking at

PulseHTTP is an HTTP/1.1 server and reverse-proxy load balancer written in Go on raw TCP, with no dependencies. This board is a faithful anatomy of one path through it. A train leaves the source, is routed, shows a bearer token at the barrier, waits for a token at the signal block, checks the cache loop, and only then reaches the origin handler. The response comes back along the scarlet line.

The route table is the server's own. Four paths, two of them protected:

PathWho may passOtherwise
/api/users/42anyone
/api/echoanyone
/api/private/profileany bearer token401
/admin/metricsthe admin role401 or 403

Station by station

  1. Source. Trains depart at the rate on the first lever. A surge sends sixteen at once, and every eleven seconds a burst of ten arrives on its own, so the signal block is seen holding traffic without anyone touching a thing.
  2. Router. An interchange with four platforms, one per path in the table above. The path decides which rules apply downstream.
  3. Auth barrier. The server separates two refusals that most stacks blur. No token on a protected path is 401: authenticate first. A valid token without the right role is 403: you are known, and still refused. Both leave the line at the red no-entry stop.
  4. Limiter. A token bucket, shown as a signal block. The lamps are tokens; each train takes one; the bucket refills at the fourth lever's rate up to the capacity on the fifth. When the lamps are out, the train is refused with 429 and a Retry-After header, and the service board reports severe delays.
  5. Cache loop. An LRU cache keyed by URL, with ETags. A repeat URL that is already cached short-turns around the green loop: 200 from cache, or 304 Not Modified when the client already holds the ETag and only needs to be told so.
  6. Origin. The handler. Trains wait in the depot while it works, then the response is cached, the least recently used entry is evicted if the cache is full, and the train returns on the scarlet line.

Try this

  • Pull Rate above Refill and watch the lamps go out. The 429 count climbs, the siding fills, and the service board turns amber. Pull it back down and the block clears at exactly the refill rate.
  • Push Repeat URLs to zero. Nothing short-turns; every train goes all the way to the origin and the cache evicts constantly.
  • Set Capacity to one. A bucket that small cannot absorb the eleven-second burst at all, which is the whole reason capacity and refill are separate levers.

Timetable: measured, not simulated

The board above is an animation of the real rules. The numbers below are not: they come from the repository's own load harness, pulsebench, run against the real server on one machine, and the README reproduces them with the exact commands.

ServiceReadingNotes
Throughput on a cached route178,996 req/sp99 2.2 ms, 200,000 requests, 0 errors
Cache lift on a CPU-bound route19.5 times8.2K to 160K req/s with LRU+ETag
Reverse-proxy balancer78,341 req/s2.7 times over one connection per request
Rate limiter blast test202 / 1,798allowed / refused with 429 and Retry-After
Conformance suite39 testsraw TCP, one status code per client failure

To check any of them: clone the repository, run go test ./..., then run the harness the README describes. Your numbers will differ with your hardware; the ratios should not.