Netflix's shared Java libraries serve applications spread across a large, independently evolving repository ecosystem. A change made in one repository can reach many others, and while producers can see the API diff in front of them, they often cannot see who still depends on the symbols that changed.
The gap widens as coding agents take on more of the software development lifecycle. An agent can speed up a local edit, but without cross-repository context it cannot judge downstream risk or help plan consumer migrations. For a library producer, the useful measurement is a blast radius: how many consumers use exactly the symbols that changed.
What existing tools miss
Take a common scenario: a deprecated API is removed after a replacement has shipped for several releases. The library's tests pass, and a compatibility checker flags the removal. Still unanswered are the questions that determine what to do next:
- Does any consumer still call the method?
- Are consumers concentrated on one version or spread across generations?
- Does another library implement or wrap the API, multiplying its impact?
- Is direct coordination enough, or is a deprecation and migration campaign needed?
Searching by hand works at small scale. Across many repositories, finding every caller and the library version it uses means digging through scattered codebases and builds. Producers who lack that evidence either ship a breaking change and learn about it from consumer failures, or keep an old API forever because the risk is unknown.
Existing techniques each cover part of the problem. Binary and source compatibility tools spot contract changes but cannot say who uses the changed API. Dependency graphs show declared reach but not whether code actually calls a method. Text search can miss overloads, inheritance, or the artifact version behind a call. Consumer builds validate strongly but are too expensive to run fleet-wide.
How Quasar works
Netflix built Quasar, an index of symbol definitions and references across its repositories, to answer two questions: what changed in a library's public API, and which repositories use those exact symbols. The second question produces the observed blast radius.
Quasar is built on SCIP, an open interchange format for semantic code intelligence. Language-specific indexers encode definitions, references, and relationships with stable symbol identifiers. Quasar keeps API definitions for library versions and commits alongside references from consumer repositories, so an API change in one repository connects to exact usages elsewhere even when the repositories were indexed separately.
Each enrolled CI build submits SCIP indexes from language-specific indexers to Quasar's ingestion service, which writes API definitions and consumer references as Parquet in Amazon S3. The stored data preserves symbol identity, dependency version, and source location.
For pull-request review, Quasar compares the indexed base and head definitions and counts direct consumer references with Amazon Athena. Findings are exposed through REST and GraphQL APIs and an MCP server, and follow-up queries return dependency-version breakdowns and source locations. When a producer supplies a changed JVM symbol, a separate compatibility-impact assessment can follow implementations and their callers.
In the deprecated-method example, the producer-side tool supplies the old method descriptor, and Quasar derives its canonical symbol identity. This excerpt from the direct-reference portion of the Athena query shows the core match:
SELECT c.change_id, 'DIRECT_REFERENCE' AS evidence_kind,
r.scm_type, r.org, r.repo, r.dep_version, r.file_path
FROM requested_changes c
JOIN quasar.symbol_refs r
ON r.symbol_canonical = c.target_canonical
The requested_changes table holds the API changes the producer submitted. The query finds repositories that call the removed method, and Quasar also follows implementations and calls through them so each affected repository is counted once. Sample dependency versions and file locations come back with the result.
Comparing pull requests and reporting confidence
Version-to-version comparison helps when planning an upgrade or writing a migration guide, but review-time feedback is more valuable. Quasar stores API definition snapshots keyed by commit; given a base and head commit, it classifies symbols as added, removed, or signature-modified, then treats removals and modifications as candidates for consumer-impact analysis.
An incompatible change is not automatically a high-risk one. Quasar reports observed impact and leaves the release policy to the producer. "No references observed" only means none were found in the indexed population: reflection, configuration, dynamic loading, stale branches, or incomplete indexing can hide consumers. Results therefore indicate whether the requested commits were indexed, how fresh the consumer indexes are, and whether evidence was truncated.
Review analysis also requires indexed snapshots of the exact base and head commits. If either is missing, Quasar reports that it cannot compare them rather than falling back to a default-branch snapshot, so a missing comparison never resembles a clean diff.
{
"change": "REMOVED",
"symbol": "Client#getLegacyValue(Request)",
"affectedRepositories": 137,
"versionDistribution": [
{ "version": "4.2.1", "repositories": 86 },
{ "version": "4.1.7", "repositories": 38 },
{ "version": "3.9.4", "repositories": 13 }
],
"sampleConsumerLocations": [
{
"repository": "checkout-service",
"filePath": "src/main/java/com/example/checkout/CheckoutClient.java",
"lines": [84, 129]
},
{
"repository": "client-wrapper",
"filePath": "src/main/java/com/example/client/ClientAdapter.java",
"lines": [57]
}
],
"libraryCriticality": {
"tier": 1,
"basis": "highest-tier downstream application"
},
"comparison": {
"baseShaFound": true,
"headShaFound": true
}
}
In this illustrative example, the repository count is specific to the symbol: 137 indexed repositories reference the removed method. Most sit on version 4.2.1, with a smaller long tail still on 3.9.4. The status location count comes from a follow-up query whose filePath and lines shape matches Quasar's query contract; only two sample locations are shown to keep the output readable. Ownership attribution is roughly estimated from related data in BigQuery using downstream repository tier annotations. The tier is context about the library, inherited from its highest-criticality downstream application, and does not mean all 137 callers are Tier 1.
With signals like these, the producer's plan changes. Rather than merging the removal and waiting for failures, the producer can keep and deprecate the old method, publish a migration path, coordinate a wider migration, and track the long-tail versions before removal. File paths and line numbers turn that scope into a concrete work list for engineers or coding agents. The same API diff paired with weak or stale evidence calls for a different action: refresh the indexes before deciding. The point is not just detecting the removal but choosing a proportionate next step.
Multiple languages, one symbol format
Because indexers resolve their own code but speak the same SCIP symbol identities, Quasar spans several language ecosystems and can find references across repositories. Client-lib indexes Client#getLegacyValue(Request) as a definition, for instance, while checkout-service indexes a reference to the same symbol, and Quasar connects the two.
Relationships matter most when generated code separates the API a producer owns from the symbols consumers invoke. Quasar can trace a Protobuf definition through its generated Java members to the repositories that use them, even if consumer code never names the .proto element.
SCIP records symbols and references; it does not judge whether a change violates an ecosystem's compatibility rules. Quasar currently compares indexed JVM and Protobuf API definitions and traces Protobuf changes through generated Java. A separate JVM compatibility path uses breaks identified by a producer-side tool to query affected repositories. Go, Python, JavaScript/TypeScript, and Rust support usage queries, but Quasar does not yet assess breaking API changes in those languages.
Earlier context for coding agents
Quasar surfaces API-change findings on pull requests today, including observed consumer counts and confidence, and its other queries expose dependency versions and source locations with library criticality as broader context. The next goal is to move that context earlier: an agent writing library code should recognize when it is changing a public symbol and consult Quasar before the change becomes a pull request. Quasar's APIs and its Model Context Protocol (MCP) integration provide access, but access alone does not create awareness — the coding workflow must also detect public API edits so the agent knows when to query impact and when to involve the producer.
Earlier guidance would not replace pull-request analysis, which still verifies the concrete diff and catches changes missed during coding. Coverage, freshness, ambiguity, unsupported platforms, and truncation must travel through both checks in machine-readable form, and an agent must never turn "no observed usages in the available index" into "safe to remove." Today agents can query Quasar through MCP when prompted; the team is working toward embedding that context in the coding workflow and using identified call sites to prepare migration changes, with the producer still responsible for API and release decisions.
Lessons and current status
Four practical lessons emerged from building the workflow.
- Separate compatibility from reach. A removed method can break the contract even with no observed callers, and a list of affected repositories and versions shows the migration ahead. Producers need both.
- Make the evidence inspectable. Pair repository counts with sample call sites and version breakdowns, and expose which commits were indexed, index freshness, and any truncation — otherwise "no usage found" reads as proof that nobody is affected.
- Keep usage and compatibility separate across languages. SCIP enables cross-ecosystem reference lookup, but deciding whether a change is breaking needs that ecosystem's rules or a trusted producer-side signal.
- Bring evidence early, while choices are open. Pull-request findings can prompt a producer to retain an API, publish a migration path, or coordinate consumers before merge; earlier delivery could shape the edit itself, and after release the same data locates consumers that need to migrate.
Quasar indexes JVM, Go, Python, JavaScript/TypeScript, and Rust code for cross-repository usage analysis, compares JVM APIs, and traces Protobuf changes through generated Java. Producers review findings via REST and GraphQL APIs or the MCP server and investigate affected repositories and call sites. The team is extending the foundation toward more ecosystem-specific compatibility checks, deeper code-review integration, and agent-assisted consumer migrations. Quasar itself is internal to Netflix, but the pattern is portable: index code semantically, retain API definitions, compare them at the point of change, query affected consumers, and report the quality of the evidence.
