Backend engineer · Bengaluru
I design and run messaging, billing and event infrastructure. Mostly: something at scale is slow, wrong, or quietly setting money on fire, and I go find out why.
Experience
Software Engineer II Apr 2026 – Present · Software Engineer Dec 2024 – Mar 2026
VideoLAN · 2024
Shipped multi-file metadata editing into VLC — the media player that has been downloaded about three billion times. Extensible metadata-provider interface, cross-file undo/redo via the command pattern, 75% fewer steps to tag a batch. Mentored by Jean-Baptiste Kempf, who founded the thing.
MuseScore · 2023
Built MuseScore 4.6's inline popup framework on Qt's model-view architecture. Later GSoC cohorts built on top of it, which is about the most flattering thing that can happen to your code. Still sending patches — 10 merged PRs across the inspector, UI framework and platform layers.
Writing
Each one is a general class of problem before it is anything I did. I hit an ugly version of all three in production — that's where the numbers come from.
01 — Queues & throughput BIK.AI
Most people don't know when to add a worker and when to raise the ingestion rate. They're not interchangeable, and picking wrong is how a 1.26M-message backlog survives 38 workers.
The fleet wasn't too small. It was feeding the backlog. Half the connections, moving more.
Read the guide →02 — Usage billing BIK.AI
Accounts drawing 2–10× what they paid for. A dollar charged for a fraction-of-a-cent call. 12.5% of revenue dropped by a daily cutoff. Every one of them silent — nothing ever errored.
All three were the same mistake: a number that decided the bill and appeared on no screen. Fixed with one versioned rate card and credits denominated in money, not counts.
Read the guide → And the timezone one →03 — Analytics BIK.AI
A dashboard over an event store has to be instant and fresh at the same time, and those pull opposite ways. Aggregating on every load took 20 seconds. Serving a saved copy meant a live campaign showed numbers from ten minutes ago.
200ms, at double the page size. Materialise the numbers, refresh only what's actually stale, and tier the recompute by how much each screen needs.
Read the guide →Also
Earlier writing on Medium and the MuseScore blog.
Projects
Nobody asked for either of these. One I use daily, one my team does.
Android TV · Kotlin · Compose
My CCTV recorder on the TV, driven entirely by the remote. The hard part isn't the video — it's the d-pad.
Zsh · Shell · Dev tooling
Type staging, get staging. Auto-loads by directory and
git branch — and never auto-loads production, because a
cd should not quietly arm your shell with prod
credentials.
Earlier repositories
About
I'm a backend engineer who designs infrastructure and then carries the pager for it. Billing ledgers, webhook delivery, event pipelines, multi-channel messaging — the layer that is invisible when it works and a company-wide incident when it doesn't.
Most of it is decided at design time, before a line gets written. A billing system is really an argument about what a credit is — a count, or an amount of money — and picking wrong costs you a rewrite and a few angry invoices. A webhook system is an argument about whose failure becomes whose problem. Draw those boundaries right and the code turns boring, which is the goal. Draw them wrong and no amount of clever code buys you out of it.
Most "scale problems" are correctness problems in a costume.
I learned that the unflattering way. The webhook system shipped before I had thought about ack deadlines at all, and merchants found the duplicates for me — the worst possible way to find them. Per-store isolation and the health evaluator both came after that call. Both are things I would now build first.
The rest of it: I read a great deal of git blame, I think the obvious explanation is usually the wrong one, and I will cheerfully spend a weekend on a CCTV app for my television because every existing one treats a remote control like a mouse.
Stack
