Ajay
Akilan.
Site reliability engineer at Zoom, in Bangalore. I look after the infrastructure behind chat. It runs in fifteen regions across three clouds, and I’ve been on it since 2021.
The system / 01
What I actually do
Zoom’s chat runs on a set of services I look after: the APIs, the real-time messaging layer, and the public edge. Fifteen regions, three clouds. I’m the service owner, so releases, incidents, capacity and cost are mine.
I’ve been on the same system for five years. You get to know which parts break, and which changes need more care than they look like they need.
What I've done to it.
Moved the services onto Kubernetes
They ran on virtual machines managed by configuration scripts, and a deploy took hours because a deploy meant touching machines. I owned the move for my services — building the infrastructure definitions and the deployment pipelines, with verification built into them rather than added afterwards.
Read itCut a seven-hour release to fifty-two minutes
Releases ran across multiple clusters on different days, and active-active doubled the surface. Verification was manual — an engineer triggering jobs in sequence and reading each result by hand — and end to end a release took about seven hours, most of it verification and waiting.
Read itREGION A LIVE
REGION B LIVE
Replaced the public edge while it was serving
The edge layer is where every request arrives. I led its replatform across the production fleet on two clouds — phased cutovers, automated verification and failover validation at each stage, no customer impact, and edge infrastructure cost on the largest cluster cut in half.
Read itREGION A LIVE
WEIGHT 100
REGION B UNAVAILABLE
WEIGHT 0
Made losing a region uneventful
Active-active was a fleet-wide programme; I ran it for the chat backend and edge services, across fourteen of fifteen production clusters. Both regions live, traffic weighted between them, failover wired into the traffic-orchestration console. Losing one means shifting DNS weight to the side still serving. New lookups resolve there, though connections already open to the failed region drop, and cached answers can keep pointing at it until they expire.
Read itActive-active / 03
Both regions live.
Traffic weighted between them, failover wired into the traffic-orchestration console. Losing one means shifting DNS weight to the side still serving — new lookups resolve there, though open connections to the failed region drop and cached answers can keep pointing at it until they expire.
DNS weighting / 01
Shift the DNS weights.
Relative DNS selection weights, not measured request percentages. Resolver caching, TTLs, health evaluation, and existing connections affect failover timing. A zero weight is not a health-failure simulation; provider-specific fallback rules may still select zero-weight records.
Outside it / 04
The other room.
I write, direct, act, and draw. I plan the trips — for my team, for my family, for friends who’ve long since stopped pretending they’ll organise anything themselves. People ask me things because it’s easy to ask me things.
None of it is separate from the job. Build the best thing you can, learn what you’re short on, put it in front of people, and stay there while it runs.
The tool / 05
Does this actually fit?
Paste the job description. I’ll send you an honest read — where I fit, where I don’t, and what a keyword screen would miss.
It says no when the answer is no.