// the find
valeriansaliou/bloom
:cherry_blossom: HTTP REST API caching middleware, to be used between load balancers and REST API workers.
Bloom is a Rust reverse-proxy cache you run alongside each REST API worker, sitting between it and your load balancer, using Redis as the backing store and HTTP response headers to drive per-route caching rules. It's aimed at teams who want caching logic to live in their API responses rather than in load balancer Lua scripts, and who are fine running one Bloom process per worker instead of a shared cache tier.
Auth-aware cache isolation is the default, not an opt-in — it hashes the Authorization header so cached responses can't leak across users, and even stores that hash rather than the raw token in Redis. Bloom Control gives you programmatic invalidation by bucket or by auth token over a small TCP protocol, so an API worker can flush exactly the stale cache it just wrote instead of waiting out a TTL. Config lives next to the route via Bloom-Response-TTL/-Buckets/-Ignore headers rather than in a separate proxy config file you have to keep in sync with route changes. It's a single Rust binary with no GC, and the stated footprint (~25MB RAM, <5% CPU at 250 RPS on an old vCPU) is the kind of number you can actually go verify yourself.
Responses are fully buffered in memory before being forwarded — the README admits this tradeoff openly, but it means a large or slow-to-generate response can spike memory, and there's no streaming path if your API ever serves big payloads. The request-coalescing lock (lock_tunnel_path) that prevents duplicate concurrent requests from hammering a cold cache is local to each Bloom process, not shared over Redis — so the one scenario it's meant to solve breaks down exactly when you run multiple Bloom instances in front of a shard, which the README's own deployment model assumes you will. Bloom Control is a bespoke protocol with its own FarmHash handshake, and only ships an official NodeJS client; any other stack means writing your own. Running one Bloom instance per API worker instead of a shared cache pool is more processes to deploy, monitor, and upgrade, and it's effectively a single-maintainer project.