- Netflix's Java Platform team describes Quasar, an internal tool that finds which repositories use a library method before a change ships.
- The lesson is that an incompatibility warning is half the evidence. Producers also need reach, plus a clear statement of how complete the data is.
- Ask whether your teams, and any AI coding tools, can see who depends on shared code, and whether 'nothing found' is treated as 'unknown'.
Changing shared software is rarely hard because of the change itself. It is hard because nobody can say who depends on it. A tool that says "this change is incompatible" gives half the answer. The other half is how many teams it touches, and how far to trust that number.
Netflix's Java Platform team has described a tool built around that idea. Roberto Perez Alcolea, writing for the Netflix Tech Blog, calls it Quasar. It is an in-house system. Other engineering teams can still study the design steps.
A passing test does not say who is affected
Netflix says its shared Java libraries serve applications spread across a large set of repositories, each evolving on its own schedule. A library change starts in one place. Its effects can land in many others. Perez Alcolea describes a gap in visibility. The team editing a library sees exactly what it altered. It has no view of the code elsewhere that relies on it.
The post uses a common case: removing a deprecated method. The library's tests pass. A compatibility checker flags the removal. The producer still cannot say whether any consumer calls the method, which versions they run, whether another library wraps it, or whether a quick word with a team is enough.
Lacking answers, the producer faces two poor options, the post says. One is to ship the change and hear about the damage when consumer builds fail. The other is to leave the old method in place forever out of caution. Neither is a decision. Both are a reaction to missing information.
How Quasar finds the callers
Quasar builds on SCIP, an open format for semantic code intelligence. Language-specific indexers record where each method is defined and where it is used. Each method gets a stable identifier, much like a catalogue number. That shared number lets Quasar link a definition in one repository to a call in another, even when the two were indexed separately.
On each enrolled CI build, the indexers send their results to Quasar's ingestion service. It stores definitions and references as Parquet files in Amazon S3, with the dependency version and source location. During pull-request review, Quasar compares the indexed base and head versions. It labels each symbol added, removed or signature-modified. It then counts direct consumer references with Amazon Athena.
The post explains why other approaches fall short. Compatibility checkers cannot say who uses an API. Dependency graphs show declared reach, not actual calls. Text search can miss overloads, inheritance and the artifact version behind a call. Running every consumer's build is strong validation but expensive.
What the producer gets
The post includes a sample report. Netflix labels it a mock-up assembled from several Quasar signals, not the literal answer of one API. The mock report lists 137 indexed repositories that point to the deleted method. Most run version 4.2.1. A smaller group is still on 3.9.4. The report also lists sample file paths and line numbers.
With those numbers, the post suggests a gentler path. Keep the method but mark it deprecated. Publish migration guidance. Watch the older versions shrink before deleting anything. The file paths become a work list for engineers or coding agents. Weak or stale evidence would point to a different step: refresh the indexes first.
The careful part: what "no users" means
Here the post is most useful. Quasar reports observed impact. It does not enforce a release policy. "No references observed" means only that none were found in the indexed population.
Several things can hide a caller from an index. Code that looks up methods at runtime is one. Behaviour set through configuration is another. So are branches nobody has built lately, and repositories the index missed. Netflix therefore wants every answer to carry three facts about itself: the commits covered, the age of the consumer data, and any cut-off in the evidence.
If the exact base and head snapshots are missing, Quasar says it cannot compare them. It does not quietly use a default-branch snapshot.
This matters more as AI coding agents take on more of the work. Agents can query Quasar through its MCP server when prompted. Netflix wants that context built into the coding workflow. It warns that an agent should not turn "no observed usages in the available index" into "safe to remove." The producer stays responsible for API and release decisions.
Limits of the account
Quasar compares JVM and Protobuf API definitions today. It can look up usage in Go, Python, JavaScript/TypeScript and Rust code. Judging whether a change in those languages is incompatible is not yet something it does. The post also reports no results, such as fewer failed releases. It is one company's description of its own tool.
Questions for your teams
Can your engineers list who calls a shared component before they change it? Does that answer say how complete and how recent the data is? If AI tools edit shared code, do they see the same evidence, and is "nothing found" treated as "unknown"? Who signs off on the release?
The lesson is simple. A warning says something may stop working. Evidence says who is affected, and how sure you can be.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Netflix.
