Skip to content
Web Data 3 min read

Scaling Collection Responsibly

Collection at scale is a privilege the open web extends to well-behaved participants. The engineering and governance practices that let a collection program grow without becoming the problem it studies.

Anyone can hammer a public endpoint. Scaling collection responsibly — growing coverage while remaining the kind of participant the open web tolerates, and ideally welcomes — is a genuine engineering discipline. This post collects the practices we've converged on after years of running collection infrastructure continuously.

Politeness is an engineering spec

"Be polite" is not a spec; the following is:

  • Per-domain budgets — concurrency and request-rate ceilings enforced in code, not in team folklore.
  • Identifiable agents — honest user-agent strings with contact information, so a source operator can reach a human instead of reaching for a blocklist.
  • Directive honoring — robots and equivalent signals respected, with edge cases escalated to humans rather than parsed creatively.
  • Off-peak scheduling — where a source has obvious load cycles, collection runs in the troughs.

These constraints are cheap. What they buy is durability: sources that don't feel abused rarely need to defend themselves, and a decade of stable sources is worth more than a quarter of aggressive coverage.

Governance scales people, not code

The hard ceilings on any collection program are governance ceilings: what may be collected, for which documented purposes, with what retention. We encode this as a program-level review — every new source gets an evaluation against the acceptable-use boundaries before a line of collection code exists. Feasibility isn't just "can we parse it" but "should we collect it, and can we defend that choice in a room of skeptical adults."

100%of sources reviewed against program boundaries before onboarding
2concurrent requests per domain ceiling — enforced, adjustable, audited
24htypical human response window when a source operator contacts us

Program defaults, enforced at the collection layer; ceilings are adjustable and audited per engagement.

The economics of good citizenship

Responsible collection is often framed as a cost. The ledger reads differently over any horizon longer than a quarter: respectful programs avoid block-induced delivery gaps, build reputational capital with source operators, and accumulate longitudinal history that aggressive programs keep resetting through bans. History depth is a moat; bans are an anti-moat.

Coverage stability: disciplined vs. aggressive collection
Disciplined programAggressive program
Source: coverage quality audit — two collection configurations tracked over 12 months. Aggressive programs trade long-term coverage for short-term speed.

What we tell new engineers

Three sentences, usually in week one: you are a guest on other people's infrastructure; the long-term dataset matters more than this week's completeness; and when policy and pressure conflict, quality and ethics win, escalate, and sleep well. A collection program that internalizes those three sentences can scale almost indefinitely. One that doesn't will eventually be scaled *down* by someone else.

If you're evaluating how a provider collects, ask for the per-domain budget spec and the source-review process. Serious programs are proud of both.

Daniel Brooks

Daniel designs the collection and normalization pipelines behind Heroku's datasets. He cares about honest error bars, boring-reliable infrastructure, and documentation that people actually read.

2 comments

Yusuke Tanaka

The coverage-stability chart tells the whole story. We inherited an aggressive program once; the ban-dip pattern was exactly as drawn.

Hannah Kim

Identifiable user agents with contact info — such a small thing, such a big difference in how source operators treat you.

Join the discussion