Distributed Systems Engineer · Bangalore, India
I design and own distributed systems end to end — architecture through production — so they stay correct at scale and affordable to run.
Almost everything I build is invisible. It's the machinery underneath an app that decides what happens next, makes sure it happens exactly once, and keeps the running cost from growing faster than the business does.
- interactions a day
- 10M+
- services owned
- 9
- integrations
- 8+
- of my commits
- 36%
Engineering notes
Problems I've had to think hard about.
Framework · designed from scratch
The abstraction was the product
Eight vendors, eight auth schemes, eight payload dialects, eight TPS ceilings. The naive version is an if/elif chain that every future engineer is afraid of — and every new client stalls a deal for months.
8+ integrations · 0 vendor branches upstream · onboarding: days → minutes
Redis · atomic TTL
Distributed debounce, no sticky sessions
A user fires six WhatsApp messages in four seconds. Three server instances each pick one up. Each thinks it's the whole conversation.
1 event per burst · N instances · 0 affinity
MediumTeaching a Bot to Wait
Dual-path pipeline
Throttling without dropping a message
End-of-day allocation pushes arrive as one enormous array. One vendor accepts 100 TPS, another accepts 5 and silently bans you for asking twice.
peak-safe · vendor-compliant · nothing dropped
Jinja2 · Metabase
Reports operations can change without an engineer
Every enterprise client wants slightly different columns, filters and delivery times. Encoding that in code means a sprint per client.
−40s query time · 100k+ row reports in SLA
Abstraction · git-style diff
A template sync engine that thinks in diffs
Message templates live in two places: in our system, and at Meta. The sync engine builds a diff matrix between the current state and the expected state — the same idea as a git diff — and turns every difference into an action. Each action then runs independently of the others.
current vs expected · diff matrix · independent actions
Voice AI · state-based prompts
Scope is the control surface
One master prompt decays as scope grows; splitting it across agents adds handoff latency a live call can't afford. I helped build a framework above the LLM endpoint that decides the conversation's state and hands the model only that state's prompt and context — so guardrails are structural, not instructional.
no master prompt · token spend down ~⅓
From LinkedIn
Knowing what's running underneath it.
The day a one-line database default beat our entire application layer
An API took 10+ minutes for one slice of data on a billion-row table. The code and indexes were fine; the planner was reasoning from stale statistics, because Postgres only re-analyzes after 10% of a table changes — 100 million rows.
10+ min → seconds · EXPLAIN ANALYZE is evidence
Aug 2026
A day of reading perfect code. The bug was underneath it.
Rows went missing while bulk inserts reported success: ignore_conflicts compiles to ON CONFLICT DO NOTHING, and UUIDv4s were colliding on shared virtual CPUs short on entropy. The fix was UUIDv7.
UUIDv4 → UUIDv7 · read the SQL your ORM writes
Aug 2026
Context belongs to the person, not the channel
Across WhatsApp and live calls at tens of thousands of messages a day, a customer's memory has to be one timeline, forget on purpose, and recall instantly. Contradictions now get resolved at the gate instead of travelling downstream.
one timeline per person · resolution rates up
Aug 2026
The path so far
Where I learned all this.
Software Engineer
Reconect.ai
Designed from scratch the plug-and-play communication framework behind 10M+ API calls/day — 8+ provider integrations whose routing, payload shapes and delivery semantics are normalised into one static interface, so calling systems orchestrate nothing.
Mar 2025 — Present
Engineering Intern
Reconect.ai
Oct 2024 — Mar 2025
Django Developer
Utoptech Consultancy
Jan 2024 — Jun 2024
Python Backend Developer
Vulmiqi
Jun 2023 — Dec 2023
Toolbox
Async Python, at volume
Correctness
Storage & transport
Get in touch
If you're building something that has to stay up.
I'm happiest near the queue, the retry policy and the part everyone else is quietly nervous about. Whether you're hiring, building something together, or just want to argue about abstractions — I read everything and I reply.
vinitagarwal.garg@gmail.com