Technical

• Agentic Development
• Distributed Systems
• Orchestration (Docker, Kubernetes)
• Web Services (REST, RPC, Java, Go, Python)
• Build Systems (Maven, Gradle)
• AWS
• Data Technologies (HBase, MySQL, Vitess, Kafka, Zookeeper, Hadoop, HDFS, Memcached, Redis, SQS, Hollow, S3)
• Web Infrastructure (DNS, TLS, NGINX, Cloudflare, WAF)

AI-Assisted Engineering

• MCP (Model Context Protocol) tool design
• LLM agent design and evaluation
• AI coding tools (Claude Code, Cursor, Conductor)
• Prompt and tool-schema design
• Verifying AI-generated code and output

Professional

• Technical Design
• Project Management
• Task Negotiation
• Incident Response
• Learning New Systems
• Communicating Technical Concepts

Soft

• Team Leadership
• Conflict Resolution
• On-Call with Empathy
• Mentorship
• Managing Social Capital

HubSpot (2019-present, Cambridge, MA)

Agentic Cluster Recommendations

desc

Agent recommends clusters for new use cases

details

Our team was responsible for Zookeeper and Memcached clusters, which are both small datastores that frequently end up under-provisioned for how they are used. This creates an issue where we have to decide between sharing clusters and risking noisy neighbor disruptions, or provisioning a new cluster and finding the right size. We receive a lot of support disruption to provision new clusters as teams build out new and exciting features. However, we noticed that many of our use cases were too small to justify provisioning a new cluster, so we didn't want to grant engineers free rein to create new clusters without guardrails.

Our solution to this was to use AI. We built out MCP tools that could round up which clusters a given team had access to and evaluate current cluster usage on those clusters. Then we were able to create an agent that could evaluate a new use case and figure out, based on how existing clusters were being used, which cluster would be the best target for the new use case, or whether a new cluster should be provisioned instead.

We hooked this agent up to our support flow, and our support disruptions from new cluster requests dropped from 3-5 per week to roughly 2 per month.

Caching and Coordination Feature Freeze

desc

Led a reliability-focused freeze that restored team health

details

By July of 2025, our team was in a pretty bad state. We had gone from 6 engineers down to 3, including the loss of our tech lead with no replacement in sight. On top of this, several recent high severity ZooKeeper incidents had created a bunch of work pushing back in-flight work. And at this time, our on-call health had deteriorated such that we were spending a week on call, a week following up on the previous week's on-call incidents, and then only having a week of focus time on our team's goals before going back on-call.

I stepped up to become acting tech lead and began tackling the situation head on. First, I elected to put our team into Feature Freeze. This forced us to take some time to evaluate priorities and focus on reliability work. Our goals included creating effective automated tests and clear operational documentation for Zookeeper, adding stronger rollout gates that took performance metrics into account for Zookeeper deployments, increasing visibility into deployment state for all of our deployments, reducing support load by automating administrative tasks for all of our data services, and automating healing of Memcached clusters scheduled on partially degraded Kubernetes nodes.

As we began working through these goals, I also began an internal recruitment campaign to bring the team back up to a reasonable size. I ultimately ended up onboarding a new team member, ramping them up to the on-call for all three of our datastores while making sure they felt supported by the team. This helped relieve the on-call pressure significantly.

By the end of Q1 2026, we were in a much healthier place as a team and exited Feature Freeze. Our on-call disruptions per week fell from ~30/week to averaging 3/week, with many weeks encountering 1 or fewer interruptions. Our datastore's reliability went up, and we were able to move on to projects that pushed us forward as a team rather than putting out fires.

By the way, I hope I've said this already, I'm really proud of what y'all accomplished in Q4. This is now the #1 team I'd want to be on as an engineer if Kartik would let me.

Memcached Auth and Encryption

desc

In-flight encryption for Memcached credentials and keys

details

Memcached is often run without TLS since it typically is not exposed to the open internet. However, to address the risk of sensitive data exposure to an attacker who has breached the VPC, we sought to enable TLS support for our Memcached clusters. Additionally, as we expanded to even more regions, our system for distributing credentials did not scale well compared to other datastores that were able to leverage our certificate authority service. First, I had to add TLS support in our fork of the Java Memcached Client. We performed various integration and load tests on TLS and ended up rolling it forward based on the data we had.

Unfortunately, our load tests did not capture production throughput as well as we had hoped, and we had to roll back our use of TLS. This created a need for a new design to manage Memcached auth as we expanded into more regions and to encrypt data in flight. I gathered input from our app auth team, principal security engineers, and the incidents caused by our old auth system, and came up with a design to use client-side encryption and distribute credentials and crypto keys securely, only to authorized clients. The proof of concept showed less than a 1% throughput degradation compared to TLS, which gave us confidence to move forward with this design. The new service also simplified how auth is handled by using an ACL model that allows teams that own Memcached clusters to add and remove accessors as needed.

JDBI Upgrade

desc

Migrated 800+ repositories onto newer JDBI 3 version

details

HubSpot's SQL client stack uses JDBI as an ORM. Most of HubSpot's code was written using JDBI 2, which stopped receiving updates in 2019. We needed to upgrade our client stack to use JDBI 3. To remove JDBI 2 from our dependency tree, I had to rewrite code in over 800 back-end repositories across thousands of Maven modules. I had to build a way to bridge existing code from the old version to the new version, which were not backwards compatible. After evaluating our usage at HubSpot and finding the limitations of a direct upgrade, I used OpenRewrite to create automation to upgrade an individual module or repo.

I then rounded up the edge cases that could not be automated away, such as those with complex dependency chains, context-dependent queries, or unusual usage patterns. This allowed me to create a guide for teams to follow to upgrade their own modules. Then I ran the automation to open hundreds of PRs for the repositories that could be automatically upgraded, and created a campaign encouraging the complex use cases to follow the guide to complete their own migration. Most teams had their client stack upgraded with minimal effort, and the remaining teams were supported every step of the way. Through this process we struck a balance between doing the work ourselves and spending social capital to get teams to do the work for us.

MySQL Cross-Region Replication

desc

Replicating global tables outside of North America

details

As HubSpot expanded into multiple regions, we began to encounter tables that needed to be read from several regions. To reduce cross-region traffic, we built a system to replicate data from North America to other regions. Standard MySQL replication was too restrictive for our needs, so we couldn't simply spin up a read-only replica in the new regions. Instead, we created a system using S3 to transfer data to other regions in a way that is durable, performant, and cost effective.

MySQL Online Schema Change Service

desc

Guardrailed online schema changes with a tracking UI

details

Over my time on the SQL team, I maintained and improved an internal tool for online schema changes for MySQL databases. Using Maven plugins to parse and import SQL schemas, I built schema guardrails to prevent incidents caused by risky or incompatible migrations. The service could then execute migrations using either PTOSC or GhOSC, depending on the change and the capabilities of each online schema change tool. This reduced friction for engineers making SQL changes by providing a UI for tracking changes, monitoring migrations, cutting over, and rolling back. We also built guardrails preventing code from being deployed before dependent migrations had been executed.

Ansible to Puppet Migration

desc

Migrated cluster configuration to pull-based Puppet roles

details

One of my first large projects involved migrating our Ansible configurations for HBase, Hadoop, HDFS, and ZooKeeper to use Puppet instead of Ansible. At the time, our HBase fleet involved dozens of clusters with hundreds of regionservers and datanodes. This meant configuration changes applied via Ansible would take days, and depended on a push-based model executed from a local machine. By migrating to a Puppet-based configuration, all configuration changes now required code reviews, and nodes would naturally update their configurations on restart. This reduced the operational overhead of configuration updates from a week-long process to a few hours of testing and code review. It also increased the reliability and security of our system by gating configuration changes behind code reviews.

HState

desc

Human-readable schemas for querying HBase data

details

HBase data is stored in byte arrays, which means there is no standard query language for running human-readable queries against it for debugging. I worked on building a backend service that manages human-readable schemas, which can be used for querying and displaying HBase data.

Lessons From The DMV: An Introduction to Queuing Theory for Microservice Performance

desc

During November, HubSpot engineering has an internal conference where anyone can give a talk about any topic, technical or non-technical. My submission was one of the 80-ish talks selected for 2024. In this presentation, I introduce queuing theory concepts so we can begin to draw connections between queues and software performance.

event

EPIC week

What Isn't Hollow

desc

When all you have is a hammer, everything looks like a nail. The side effect of making Hollow easy to use is that teams begin to reach for it when it isn't the right tool for the job. In May of 2026, I gave a talk to all of HubSpot Engineering to dive into Hollow internals and evaluate alternative Data Infra offerings for when Hollow is not the right choice.

event

Tech Talk