Manjari Akella

Manjari Akella is a senior software engineer on Uber’s Developer Platform team. She helped establish the Go monorepo, where engineers across Uber develop Go code in a shared repository. When AI-assisted coding pushed merge times into hours, she helped adapt SubmitQueue, the system that tests how changes work together before merging them.

Manjari’s early work was in computer vision. She experimented with estimating the positions of joints hidden from a Kinect sensor and choosing how finely to divide an image into regions for object recognition. She earned a master’s degree in computer science and engineering from Ohio State in 2015. Computer vision projects · Ohio State commencement program

Before joining Uber in 2018, Manjari contributed to a collaboration between IBM Watson and IBM Research. The engineers were building an application while researchers were still developing its algorithms. A common interface let the researchers revise their models while the engineers worked on how to schedule training and serve results. At Uber, Manjari’s work on the Go monorepo extended to improving the libraries developers used within it. IBM project history · Manjari’s Go work at Uber

Moving build artifacts to the cloud

Manjari worked with Preetam Dwivedi on moving Uber’s build artifacts to a managed cloud service. The move relieved engineers of having to rebalance full disks and recover data from failing machines. It also made repeated downloads expensive. Uber’s builds downloaded more than five petabytes of artifacts a month, often fetching the same library many times.

The team built a validation proxy that checked each request with the cloud service. If the service confirmed that the file was unchanged, the proxy served the local copy. If the file had changed, the proxy streamed the new version to the build and updated its cache in the background. Manjari and Preetam reported that this cut the volume of data leaving the cloud service by more than 99% and reduced artifact-related data transfer costs by nearly 90%, with download times comparable to the previous system. Modernizing Artifact Storage at Uber

Who waits for a merge

Manjari singled out the cost to shared-library maintainers when SubmitQueue began rejecting expensive changes at peak hours. A small edit to a widely used library could affect enough build targets to make testing it expensive. The rule let more changes merge each hour, but the maintainer had to return off-hours to resubmit. The team added a deferral queue that held the request and released it when capacity opened up. The change still had to wait. Its author could submit it once.

The team also reconsidered which changes needed to be tested together. SubmitQueue scored how much their build targets and dependencies overlapped, kept strongly overlapping changes together and let weakly overlapping ones proceed in parallel. It made that decision when each request arrived so builds already under way could finish and their results could still be used. Manjari reported that peak throughput rose from about 160 merges an hour to nearly 250. The team accepted a specific risk in return. Two changes could pass separately and break the main branch when combined, so Uber also tested the code after it merged and tracked the last revision that passed. Manjari and Preetam on Uber’s merge queue