SearcharxivSearch

arXiv subjects

Manideep Reddy Chinthareddy

Publications and source records attributed to Manideep Reddy Chinthareddy.

4 recordsLinked to original sources

Reliable Graph-RAG for Codebases: AST-Derived Graphs vs LLM-Extracted Knowledge Graphs

Retrieval-Augmented Generation for software engineering often relies on vector similarity search, which captures topical similarity but can fail on multi-hop architectural reasoning such as controller to service to repository chains, interface-driven wiring, and inheritance. This paper benchmarks three retrieval pipelines on Java codebases (Shopizer, with additional runs on ThingsBoard and OpenMRS Core): (A) vector-only No-Graph RAG, (B) an LLM-generated knowledge graph RAG (LLM-KB), and (C) a deterministic AST-derived knowledge graph RAG (DKB) built with Tree-sitter and bidirectional traversal. Using 15 architecture and code-tracing queries per repository, we measure indexing time, query latency, corpus coverage, cost, and answer correctness. DKB builds its graph in seconds, while LLM-KB requires much longer graph generation. LLM-KB also shows indexing incompleteness: on Shopizer, 377 files are skipped or missed, reducing embedded chunk coverage and graph size compared to DKB. End-to-end cost is modest for DKB relative to the vector-only baseline but much higher for LLM-KB, especially as repository scale increases. Query latency is similar for No-Graph and DKB, while LLM-KB is slower and more variable. On the Shopizer question suite, DKB achieves the highest correctness, LLM-KB is close behind, and the vector-only baseline performs worst on upstream architectural queries and has the highest hallucination risk. Overall, deterministic AST-derived graphs provide more reliable coverage and multi-hop grounding than LLM-extracted graphs at substantially lower indexing cost.

cs.SE

Enterprise Identity Integration for AI-Assisted Developer Services: Architecture, Implementation, and Case Study

AI-assisted developer services are increasingly embedded in modern IDEs, yet enterprises must ensure these tools operate within existing identity, access control, and governance requirements. The Model Context Protocol (MCP) enables AI assistants to retrieve structured internal context, but its specification provides only a minimal authorization model and lacks guidance on integrating enterprise SSO. This article presents a practical architecture that incorporates OAuth 2.0 and OpenID Connect (OIDC) into MCP-enabled developer environments. It describes how IDE extensions obtain and present tokens, how MCP servers validate them through an identity provider, and how scopes and claims can enforce least-privilege access. A prototype implementation using Visual Studio Code, a Python-based MCP server, and an OIDC-compliant IdP demonstrates feasibility. A case study evaluates authentication latency, token-validation overhead, operational considerations, and AI-specific risks. The approach provides a deployable pattern for organizations adopting AI-assisted developer tools while maintaining identity assurance and auditability.

cs.SE

Stateless Snowflake: A Cloud-Agnostic Distributed ID Generator Using Network-Derived Identity

Snowflake-style distributed ID generators are the industry standard for producing k-ordered, unique identifiers at scale. However, the traditional requirement for manually assigned or centrally coordinated worker IDs introduces significant friction in modern container-orchestrated environments (e.g., Kubernetes), where workloads are ephemeral and autoscaled. In such systems, maintaining stable worker identities requires complex stateful sets or external coordination services (e.g., ZooKeeper), negating the operational benefits of stateless microservices. This paper presents a cloud-agnostic, container-native ID generation protocol that eliminates the dependency on explicit worker IDs. By deriving node uniqueness deterministically from ephemeral network properties - specifically the container's private IPv4 address - the proposed method removes the need for centralized coordination. We introduce a modified bit-allocation scheme (1-41-16-6) that accommodates 16 bits of network-derived entropy while preserving strict monotonicity. We validate the approach across AWS, GCP, and Azure environments. Evaluation results demonstrate that while the design has a theoretical single-node ceiling of approximately 64,000 TPS, in practical microservice deployments the network I/O dominates latency, resulting in end-to-end performance (approximately 31,000 TPS on a 3-node cluster) comparable to classic stateful generators while offering effectively unbounded horizontal scalability.

cs.DC

A Chunked-Object Pattern for Multi-Region Large Payload Storage in Managed NoSQL Databases

Many managed key-value and NoSQL databases - such as Amazon DynamoDB, Azure Cosmos DB, and Google Cloud Firestore - enforce strict maximum item sizes (e.g., 400 KB in DynamoDB). This constraint imposes significant architectural challenges for applications requiring low-latency, multi-region access to objects that exceed these limits. The standard industry recommendation is to offload payloads to object storage (e.g., Amazon S3) while retaining a pointer in the database. While cost-efficient, this "pointer pattern" introduces network overhead and exposes applications to non-deterministic replication lag between the database and the object store, creating race conditions in active-active architectures. This paper presents a "chunked-object" pattern that persists large logical entities as sets of ordered chunks within the database itself. We precisely define the pattern and provide a reference implementation using Amazon DynamoDB Global Tables. The design generalizes to any key-value store with per-item size limits and multi-region replication. We evaluate the approach using telemetry from a production system processing over 200,000 transactions per hour. Results demonstrate that the chunked-object pattern eliminates cross-system replication lag hazards and reduces p99 cross-region time-to-consistency for 1 MB payloads by keeping data and metadata within a single consistency domain.

cs.DB