A well-cached public service still needs fair use boundaries

A public service can be efficient at serving requests and still let one application make it worse for everyone else. Capacity planning alone cannot decide who should bear the consequences of concentrated demand. A shared map service also needs a way to identify downstream applications, contact their owners and contain one application's traffic without treating every visitor as the same problem.

Looking back from November 2026, Zsolt Ero's 9 August 2025 OpenFreeMap account makes that distinction concrete. He attributed the surge to Wplace.live, reported 30 million requests over five minutes, and expressed that as 100,000 requests per second. He also reported a 99.4% CDN cache rate and roughly 1,000 requests per second at his servers. These are the operator's figures for that incident, not an independently reproduced capacity test.

Start by naming the unit

Requests per second are neither concurrent users nor map sessions. One person can cause several tile requests, and a request served at a CDN is different work from one reaching the origin. The figures in the account should remain attached to their workload and observation window. Combining them into a general promise about how many people another map application can support would lose those conditions.

Even a high cache hit rate leaves other resources to manage. Connections, file access and the work that reaches the origin can matter independently of the percentage served from cache. The post describes missing tiles and an intervention against the downstream application. It does not provide a universal threshold at which every similarly designed service will fail.

Nor should a reader force rounded dashboard figures into an exact arithmetic reconstruction. The five-minute request count and the separately reported origin rate do not establish that every number uses an identical interval and denominator. The useful conclusion is the distinction between edge and origin work. A precise capacity claim would require aligned measurements that this article does not supply.

For a product owner, this makes the first investigation less glamorous and more useful. Ask what is being counted, where it is counted and what users could actually complete during the incident. A successful HTTP response is not automatically a successfully drawn map. This is a proposed evaluation approach, not a new measurement of OpenFreeMap.

The application is a separate responsibility boundary

The person operating a public map endpoint may see requests from many individual browsers. The commercial or community decision, however, may concern a single application directing all those browsers. Limiting each visitor separately can leave the concentration untouched while penalizing unrelated users who happen to share a network.

An identifiable application boundary gives the operator another option. They can discuss launch expectations with its owner, agree on escalation and decide when a different hosting arrangement is appropriate. That boundary does not require treating every public service as a paid account product. It requires enough information to associate concentrated use with someone who can change the application causing it.

Ero's account describes both contact before another project's launch and a rule introduced during this incident. That is evidence of his response, not proof that one header provides perfect application identity. A browser referrer may be absent, and a client-supplied label is not authenticated ownership. Operational identification and a security boundary should not be confused.

The practical choice depends on the service's openness. A fully anonymous endpoint offers very low adoption friction but gives its operator fewer reliable ways to isolate a downstream product. Registration or authenticated access may improve accountability while adding support work and excluding some legitimate uses. That is a product tradeoff, not a defect that more cache can repair.

More capacity remains a serious alternative

The strongest counterargument is that public infrastructure exists to be used. A successful downstream application is not automatically abusive, and restrictions can undermine the public benefit the service was built to provide. If demand is affordable and sustainable, adding capacity may be the right response.

That argument deserves a real budget and an owner. Sponsored bandwidth can help with one expense without supplying unlimited operations time or guaranteeing every other resource. The source is one operator's account of a specific arrangement in August 2025. It is not evidence of present sponsorship terms or a transferable commercial entitlement.

Fairness also need not mean an equal request allowance for every application. A service might support an agreed large public project while containing a smaller but poorly behaved client. The decision should follow its purpose and maintenance constraints. Silent improvisation becomes harder to defend when downstream owners have no way to know what behavior the operator expects.

Give downstream owners a next step

A useful public policy explains who to contact before a large launch and what information makes that conversation actionable. Expected request patterns, cache behavior and the effect of unavailable tiles matter more than an unsupported user-count forecast. State how the owner can reduce demand or move to a separately operated endpoint if the shared one cannot carry it.

For custom software development, include that dependency conversation in launch planning. Describe what the application does when its map provider limits access, and who can change the integration. No load test or traffic measurement was performed here. The architectural lesson is still clear: efficient delivery gives a shared service room to operate; an accountable application boundary gives its operator a way to preserve that room for others.