A project published on GitHub, Bounded Origin, offers website operators a way to stop floods of web requests from overwhelming their servers with expensive calculations. Described as an HTTP gateway and Java library, it lets equivalent requests share one computation, places explicit limits on new work and can keep saved results so they survive a server restart.
The problem: cost is not the same as request count
Operators often measure load by counting requests. According to the project's README on GitHub, that view misses a key distinction. Serving a finished result can be cheap, while producing it can be very expensive. Many different URLs may ask for the same underlying work, and distinct requests can keep generating new work whenever a cached copy is missing. In that situation, a traffic spike can translate into heavy computation even when the number of visitors looks modest.
Bounded Origin addresses this by letting operators define which inputs identify the same operation. Requests that resolve to that operation can share a single computation instead of each triggering its own. Operators also set global and per-policy caps on how much work runs at once and how much can wait in a queue. When those caps are reached, excess requests receive a 503 status with a Retry-After header, signalling that clients should try again later. Requests that cannot be classified are denied.
How the gateway works
The README says the configuration guide covers routing, budgets and five policy strategies. Operators map incoming requests to operations, then assign budgets that govern active and queued work. Saved results can be reused across restarts, which means a result computed once does not have to be rebuilt after the service comes back up.
- Equivalent requests can share one computation.
- New work runs within explicit limits on active and queued jobs.
- Excess requests receive a 503 response with Retry-After.
- Unclassified requests are denied.
- Saved results can persist across restarts.
The gateway runs from a YAML configuration file and requires Java 21. The 0.1.0 distribution is available as a tar archive for POSIX systems or a zip file for Windows, with dependencies included. The quick start in the README uses a demo origin written in Python 3. Two equivalent requests are sent in succession: the first computes and saves the result, and the second reuses it. State is stored in a dedicated data folder, and listeners bind to loopback addresses.
A Git hosting example
Pre-rendering cgit pages
The project includes an independent application called Bounded Origin Git, built on the released 0.1.0 libraries. It serves cgit pages that are rendered ahead of time, so anonymous visitors do not trigger rendering on the origin. cgit is a web interface for browsing Git repositories, and page generation is the kind of work that becomes costly when crawlers request large numbers of pages.
The README reports results from a Linux and cgit campaign. Across 47,200 measured Bounded Origin attempts, anonymous requests caused zero native cgit executions. In a crawl of 512 unique pages, the prepared setup delivered all 512 representations in each of ten measured repetitions, again without any request-triggered cgit runs.
The approach carries a tradeoff. Preparation required 512 trusted renders, and pages that were not prepared return a 404 response. The README also notes that client-side comparisons involve their own cost and coverage tradeoffs, and it points readers to full results, preparation costs and reproduction instructions.
Benchmarks and the latency cost
A separate mechanism benchmark compares a synthetic CPU origin with two gateway strategies: shared computation, labelled BOUNDED_COMPUTE, and saved results, labelled MATERIALIZE. The tests used the packaged gateway on Java 21 inside a shared WSL2 environment. For 256 requests naming one operation at concurrency 64, across ten measured repetitions, both strategies ran with active capacity 1 and queue capacity 0.
The benchmark also shows a latency cost. In a separate sequential-request comparison, the median of per-trial p99 latencies was 81.5 ms through BOUNDED_COMPUTE, compared with 20.4 ms when requests went directly to the origin. The README adds that routing and operation-key costs grow as configuration becomes more complex.
What operators should check before deploying
The README is direct about its assumptions. Responses must be safe to share publicly, and stored results must remain valid for their versioned identity. Caller-specific, authenticated, conditional and range responses fall outside the model, and the origin must affirm public sharing.
- Confirm that responses are safe for public sharing.
- Do not assume a timeout means computation has stopped.
- Preserve the exclusive ownership state across restarts.
- Route all bounded work through that ownership domain.
The project warns that uncertain work keeps its capacity indefinitely, including across restarts, which makes ownership and recovery planning a prerequisite for deployment. It also stresses that Bounded Origin complements, rather than replaces, authentication, TLS termination, rate limits and CDN or WAF controls. It does not identify bots or stop incoming traffic on its own.
Licensing and outlook
The runtime is licensed under AGPL-3.0-only, while the bounded-origin-api component is licensed under Apache-2.0. The README directs readers to separate pages covering licensing terms and security reporting.
The project addresses a problem many site operators face: a small number of expensive pages can consume far more resources than their share of traffic suggests. Whether the approach fits a given site will depend on how cleanly its requests map to shared operations and how safely its responses can be shared publicly. Readers evaluating the project should start with the configuration guide and the response contract.
Related: FilzaFiles: A Lightweight Java Library for File Operations · Magic Hotspot: Connect Linux to an iPhone Hotspot
Comments (0)