$ ssh gaurav@bengaluru
authenticating… ok
mounting /experience (9+ years, 0 data loss)
warming caches, brewing chai…
$ ./portfolio --render
press any key to skip
Bengaluru, IN  ·  status: 200 OK

Gaurav Verma
builds systems
that don't blink.

> Principal / Staff Software Engineer|

Principal / Staff engineer working on distributed, data-intensive and AI-enabled platforms. Give me a deadline measured in minutes, a dataset that won't fit in memory, and a cloud bill someone wants halved — I'll hand back infrastructure so boring it never pages anyone at 3 AM.

📍 Bengaluru📞 +91 99711 53201🎓 B.Tech IT, DTU (DCE)
gaurav@principal — engineer.py
# design happens long before the first line of code class GauravVerma(PrincipalEngineer): def design(self, problem): why = self.constraints(problem) # scale, SLA, cost hld = self.boundaries(why) # data flow, ownership lld = self.contracts(hld) # schemas, idempotency # what turns a diagram into a design for f in self.what_breaks(lld): assert f.is_contained # blast radius assert f.is_observable # traced, not guessed assert f.is_recoverable # retry, replay, revert assert f.loses_nothing # no silent data loss return self.simplest_thing_that_survives(hld, lld) def what_breaks(self, system): yield from ( "the network", "the network, but only one way", "a dependency that got slow, not down", "a crash mid-write", "the same event twice", "a webhook that landed while we were down", "a write that landed, an event that didn't", "two leaders, both certain", "a clock that lies", "a replica three minutes behind", "one hot key", "retries, in unison", "a queue that only grows", "a cache, cold, at 9am", "exactly-once, allegedly", "the tenant with 100x the data", ) python -c "GauravVerma().design(your_hardest_problem)"
0+
years shipping production systems
0M
row-level computations / 15-min SLA
0M
monthly active users served
$0K
annual observability cost removed
0×
faster result persistence (90s → 4s)
0TB
moved per pipeline run, zero buffering
~/ whoami --verbose

Backend by trade.
Systems thinker by default.

I spend my days between the request and the database — the part nobody sees until it's slow, wrong, or expensive. That's the part I like.

/** * @summary Principal-level engineer designing distributed, * data-intensive and AI-enabled platforms. * * @does Architecture · event-driven systems · multi-tenant SaaS * performance engineering · observability · agentic AI * * @believes The best platform is the one three teams reuse * without ever reading your docs. * * @leads Teams through architecture, delivery and the * unglamorous 2 a.m. production incident. * * @throws TooManyMeetingsError */

Latency is a feature

90s → under 4s. 60% off API response times. If a number can go down, I take it personally.

🧱

Platforms > one-offs

Pluggable strategies, reusable libraries, provider-agnostic layers. Built once, adopted org-wide.

💸

Cost is an SLO too

~$21K/yr of APM spend deleted. ~50% infra cost cut on a 500M-document search cluster.

🧭

Leads from the codebase

Mentored teams of 5, directed delivery, and still the one reading the flame graph.

// the stack of me — hover a layer

Product & constraintsthe "why"
API & orchestrationFastAPI · Django
Agents & LLM routingLangGraph · MCP
Async & event backboneKafka · Celery · Cloud Tasks
Compute & optimisationPolars · DuckDB · Gurobi
Storage & searchPostgres · Redis · Elastic
Observability floorOTel · Tempo · Grafana
chaibrain.pyO(n log n)shipped
~/ cat requirements.txt

The toolbox, honestly labelled.

No logo soup. These are things I've run in production, on-call, at scale — grouped the way I actually reach for them.

🏗️

Architecture

v9.0.0
Distributed SystemsEvent-DrivenMicroservicesMulti-Tenant SaaSHigh ConcurrencySystem Design
🐍

Languages & Backend

stable
PythonRustSQLFastAPIDjangoREST APIsCelery
🧮

Data & Optimisation

tuned
KafkaRedisPostgreSQLMongoDBElasticsearchBigQueryPolarsDuckDBGurobi
🤖

AI, Cloud & Reliability

latest
LangGraphMCPOpenAIAnthropicGCPAWSDockerCloud RunOpenTelemetryGrafanaTempoELK
~/ git log --author="Gaurav Verma" --oneline

Nine years, four repos, one habit.

Click any commit to expand the diff. Warning: contains real numbers.

a7f3c9d

Impact Analytics — Tech Lead

Jul 2024 → present
PythonFastAPILangGraphMCPOpenTelemetryPolarsDuckDBGurobiGCP
  • Enterprise Agentic AI platform. Designed the backend architecture for an enterprise conversational platform on Python, FastAPI, LangGraph, MCP servers, OpenAI and Anthropic — letting agents talk to enterprise tools and data securely, not hopefully.
  • Agent orchestration & extensibility. Stateful multi-step workflows, tool routing, reusable platform components, and a provider-agnostic multi-LLM layer so no single model vendor owns the roadmap.
  • Org-wide observability platform. Architected mtptrace, a reusable OpenTelemetry library shipped across FastAPI microservices; replaced commercial APM with Grafana Tempo and cut trace-storage cost by ~$21,000/year.
  • Zero-touch instrumentation. Runtime module discovery, wrapt-based auto-instrumentation, AST analysis, build-time caching, configurable sampling, error-preserving span filters, tenant-aware tracing, trace-log correlation, automatic PostgreSQL query visibility. Teams got tracing by importing.
  • Purchase-order allocation engine. Architected a platform turning each PO into ~1–2M store-level allocation records under a hard 15-minute SLA across products, sizes, stores, DCs, packs and forecast weeks.
  • Performance at scale. Result-persistence latency from 90s → under 4s (>20×) using DuckDB COPY, PostgreSQL temp tables, schema-aware coercion and in-engine data cleansing.
  • Resilience & capacity. Cloud Tasks fan-out at concurrency 50, fault-isolated retry queues, and load tests sustaining 100 concurrent POs / 150–200M row-level computations inside the SLA.
  • Optimisation architecture. A Polars-based, pluggable six-strategy allocation framework with Gurobi linear programming for pack- and capacity-constrained store distribution.
  • Terabyte-scale delivery. A BigQuery → GCS → SFTP orchestrator-worker pipeline moving up to ~1 TB per run without buffering in application memory — bounded concurrency, durable retries, idempotency, per-tenant config.
4e1b60a

rolf.fit — CTO

Apr 2022 → May 2024
DjangoFastAPINext.jsReact
  • Product & platform ownership. Built the company's technology stack from the ground up with Django, FastAPI, Next.js and React — translating operational requirements straight into production software.
  • Configurable booking platform. A backend-controlled slot-booking system absorbing changing service durations and operating rules without repeated application rewrites. Config where others hardcode.
9c2ad14

WorkIndia — Senior Full Stack Developer

Nov 2019 → Jan 2022
ElasticsearchKafkaRedisMongoDBDjango
  • High-scale recommendations. A jobs recommendation system on Python, Django, Elasticsearch, Redis, MongoDB and Kafka for a platform at 10M MAU / 1M DAU.
  • Performance optimisation. Cut API response time by 60% and tuned a 500M-document Elasticsearch platform — shard sizing, node topology, indexing strategy, cluster tuning — dropping infra cost by ~50%.
  • Distributed caching. Redis sharding with consistent hashing for horizontal scalability, fault isolation and resilience under lumpy traffic.
  • Engineering leadership. Directed delivery and mentored 5 developers across design, implementation and production support.
1a0f7e3

Blowhorn — Software Engineer

Aug 2016 → Oct 2019
DjangoLogistics0 → 1
  • Last-mile delivery platform. Built a Django delivery product from scratch and helped scale operations from hundreds of weekly orders to lakhs.
  • Team & product delivery. Led three engineers on last-mile and built the Kirana-shop delivery module from inception.
0000000

Delhi Technological University — B.Tech, Information Technology

2012 → 2016
initial commitformerly DCE
~/ ls projects/ --deep-dive

Six systems, drawn out loud.

Every project I'd sketch on a whiteboard if you asked me "so what have you actually built?" — nine years of them, newest first.

01 — Impact Analytics

The purchase-order allocation engine

Each PO explodes into 1–2M store-level allocation records across products, sizes, stores, DCs, packs and forecast weeks — and the whole thing has 15 minutes. Cloud Tasks fan-out at concurrency 50, fault-isolated retry queues, six pluggable Polars strategies, and Gurobi linear programming where the packs and capacities fight back.

1–2M records / PO15 min hard SLA100 concurrent POs6 strategies
PO ingestedt = 0:00Cloud Tasks fan-outconcurrency 50 · retries isolatedPolars6 strategiespluggableGurobi LPpack + capacityconstrainedDuckDB COPYtemp tablesschema coercion1–2M rows persistedt < 15:00 ✓150–200Mcomputations
02 — Impact Analytics

mtptrace — observability, by import statement

A reusable OpenTelemetry library distributed across FastAPI microservices. Runtime module discovery, wrapt-based auto-instrumentation, AST analysis, build-time caching, configurable sampling, error-preserving span filters, tenant-aware traces, trace-log correlation and automatic PostgreSQL query visibility. Commercial APM went out; Grafana Tempo came in; ~$21K/year stayed in the budget.

~$21K/yr saved0 lines to instrumentorg-wide adoption
svc-orderssvc-allocsvc-agentsimport mtptrace…that's the whole setupmtptracewrapt + ASTtenant-aware spansTempoGrafanacommercial APMdeprecated · -$21K/yrzero-touch instrumentation
03 — Impact Analytics

A terabyte, moved without touching RAM

BigQuery → GCS → SFTP, orchestrator-worker style, up to ~1 TB per run streamed straight through — never buffered in application memory. Bounded concurrency so the network stays polite, durable retries and idempotency so a half-finished run is never a corrupt one, and tenant-specific configuration because every customer's SFTP box has opinions.

~1 TB per run0 B buffered in appidempotent retries
BigQuery~1 TBGCSstaged shardsorchestratorbounded concurrencyworkerworkerdurable retries · idempotentSFTPper-tenantapp memory0 bytes bufferedstreams, not slurpsthe pipeline never blinks, and never OOMs
04 — WorkIndia

The jobs recommendation engine

A recommendation system on Python, Django, Elasticsearch, Redis, MongoDB and Kafka, serving 10M monthly and 1M daily users looking for work. The interesting part wasn't the ranking — it was keeping a 500M-document index fast and affordable: shard sizing, node topology, indexing strategy and cluster tuning took API response time down 60% and infrastructure cost down roughly half.

10M MAU · 1M DAU500M documents−60% API latency−50% infra cost
job seeker1M DAUDjangoREST APIElasticsearch500M docs · tuned shardscache readRedisconsistent hashing ringKafkaevents → MongoDBp95 −60%cost −50%same results,half the clusterranking is easy. ranking for 10M people, cheaply, is the job.
05 — rolf.fit

A booking platform that outlives its own rules

As CTO I built the company's stack from nothing — Django, FastAPI, Next.js, React — and the piece I'm proudest of is the least visible one: a backend-controlled slot-booking engine. Service durations, operating hours and booking rules all live in configuration, so the business could change how it works on a Tuesday without anyone rewriting the application on Wednesday.

0 → 1 entire stackconfig-driven rules0 rewrites needed
configduration: 45mhours: 06–22rules: [buffer, cap]slotenginegenerated availabilitygreen = bookable, decided at runtimethe alternativeif service == "x":…foreverDjango · FastAPI · Next.js · React — built from zerobusiness rules changed weekly. the code didn't.
06 — Blowhorn

Last-mile delivery, from scratch to lakhs

My first system, and still a favourite: a Django-based last-mile delivery product built from an empty repository, which then had to survive the company scaling from hundreds of weekly orders to lakhs. I led three engineers on it and built the Kirana-shop delivery module from inception — hyperlocal orders, real riders, real streets, and no tolerance for a dispatch that silently drops.

hundreds → lakhs of orders3 engineers ledKirana module, 0 → 1
order inKirana shopdispatchDjangoriderassignedriderassignedroutes · SLAs · proof of delivery2016 · hundreds / week2019 · lakhsthe graph that taught me about scale
~/ metrics --watch --before-after

Numbers that moved.

Every bar below is a real production system, before and after someone got annoyed enough to fix it. (It was me. I was someone.)

Result persistence latency90s → <4s  (>20× faster)
90s · before
4s
DuckDB COPY + temp tables
API response time (10M MAU platform)−60%
baseline
40%
Elastic + Redis tuning
Search infrastructure cost (500M docs)−50%
baseline
50%
shard sizing · node topology
Trace storage spend−$21,000 / year
commercial APM
Tempo
self-hosted, same visibility
SLA headroom on 200M computationsinside 15 min, at 100 concurrent POs
SLA budget · 15:00
measured under load
load-tested, not hoped
~/ sh — yes, this one actually works

Don't read the site. Query it.

A real shell over my résumé. Type help and poke around. There are easter eggs.

bash — gaurav@portfolio: ~zsh
gaurav@portfolio ~ %
status: open to hard problems

Got a system that keeps you up?

Distributed architecture, agentic AI platforms, a latency number that refuses to move, or a cloud bill that won't stop growing — those are my favourite conversations.

curl -X POST gaurav.dev/opportunities -d '{"problem":"hard","scale":"large"}'