Quasar: Measuring Blast Radius of API Changes in a Large Microservice Ecosystem

In a large, distributed system like Netflix's, with numerous independent repositories and shared Java libraries, managing API compatibility is a significant challenge. A change in one library can have a widespread impact on many downstream consumers. Traditional methods like API diffs, dependency graphs, or text searches are often insufficient to accurately determine which specific consumers are using a changed API and on which versions they depend.

The Problem: Lack of Visibility into API Usage

Producers of shared libraries often face a dilemma: evolve the library to add new features or remove deprecated APIs, but risk breaking consumer applications. Without precise visibility into live API usage, they must either delay necessary changes indefinitely or proceed with high risk, potentially causing widespread failures. This problem is exacerbated by the growing use of coding agents that can accelerate local changes but lack cross-repository context for downstream risk assessment.

Quasar's Architecture and Key Components

Quasar is built on SCIP (Semantic Code Intelligence Protocol), an open interchange format for semantic code intelligence. Language-specific indexers generate SCIP indexes that encode definitions, references, and relationships, which are then submitted to Quasar's ingestion service. This service stores API definitions and consumer references in Parquet format within Amazon S3. During pull-request review, Quasar uses Amazon Athena to query these indexed data, comparing base and head definitions and counting direct consumer references.

• SCIP Indexers: Language-specific tools that parse code and generate SCIP data, capturing symbol definitions, references, and relationships.
• Ingestion Service: Receives SCIP indexes from CI builds and stores them in S3 as Parquet files, retaining symbol identity, dependency version, and source location.
• Amazon S3: Used for scalable and durable storage of indexed API definitions and consumer references.
• Amazon Athena: Utilized for powerful, serverless querying of the Parquet data to identify affected repositories and their dependency versions.
• APIs (REST, GraphQL, MCP): Expose Quasar's findings to developers, providing impact reports with affected repository counts, version distribution, and sample source locations.

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

Quasar provides a comprehensive impact report that includes the type of change (e.g., REMOVED), the specific symbol affected, the number of affected repositories, their version distribution, and sample consumer locations. This rich evidence allows library producers to make informed decisions, such as coordinating migrations, retaining deprecated methods, or delaying removals, thereby promoting intentional evolution of shared libraries and preventing widespread system instability.

Moving Risk Assessment Earlier in the Development Workflow

A key goal for Quasar is to integrate this impact analysis earlier into the development lifecycle, ideally during code authoring by developers or coding agents. Providing context about public API changes and their potential blast radius before a pull request is even opened can significantly reduce rework and risk. While PR analysis will remain crucial for final verification, early feedback empowers developers to proactively address compatibility issues.