Pavan Dangeti

SDE projects

Each project leads with its outcome, says how it was measured and states its limits. 5 projects.

1,000 concurrent orders for 100 units, and exactly 100 confirmed

Never oversells stock, even when many orders arrive at once or a service crashes mid-order. Built for order and fulfilment systems.

Eliminated overselling under load, with exactly 100 of 1,000 concurrent orders confirmed for 100 units (a check-then-write baseline accepted 921–969), by using a conditional UPDATE backed by a CHECK constraint.

SDEShipped

Oversold under 1,000 concurrent orders
0
Baseline: 921–969 of 1,000 told yes by a check-then-write
1,000 concurrent HTTP orders for 100 units at 100 clients, then nine cross-store invariants (scripts/ordering-harness.py); the baseline is measured at the reservation layer, three runs
The FulfillOps ops floor, a 3D view of orders moving through the saga

A job queue where a crashed or zombie worker can't apply an effect twice

A durable job queue for background work that must not be lost or applied twice, for Go services on PostgreSQL.

Applied every job's effect at most once, with 60 of 60 jobs completed and zero fencing violations under crashes, pauses, a Postgres restart and dropped connections, by guarding writes with fencing tokens.

SDEShipped

Throughput, 500 jobs
1,243 jobs/s
Baseline: River 298–643 jobs/s, by fetch setting
4 worker loops × 8 in flight, debounced NOTIFY, same Mac and Postgres 17 for both (results/benchmarks-2026-10-08.json); start latency is the cost, p50 23 ms against River's 2 ms at its fastest setting
The Conveyor dashboard showing the default queue with 60 completed jobs

An OCR pipeline that never acts on a number it can't prove

A personal timesheet-OCR project, built and benchmarked on synthetic data, that verifies hours against each sheet's own totals.

Read 96 of 220 held-out synthetic timesheets exactly, against 27 for Tesseract 5, by locating the grid with OpenCV and recognising each cell on its own crop.

SDEAI/MLShipped

Held-out sheets read exactly
96 of 220
Baseline: Tesseract 5, 27 of 220
220 held-out generated sheets, each with one degradation (blur, skew, noise, JPEG, shadow, low resolution, stamps, pen marks, handwriting, simulated photos), read on x86-64 in CI (docs/ocr-benchmark.md). Synthetic data only
VeriTrack AI analysis results on synthetic data, listing two employees whose timesheet leave is missing from the leave register

Fit a WebGPU particle world into 304 KB, loaded after first paint

This portfolio: a WebGPU particle world held to strict performance, accessibility and testing budgets.

Kept the 3D engine to 304.6 KB after first paint, within a 320 KB budget, by running every formation through one branch-free compute kernel on WebGPU and WebGL2.

SDEAI/MLLLMShipped

Graphics engine
304.6 KB
Baseline: 320 KB budget
Gzipped JavaScript the engine adds after first paint, measured on the built site by scripts/budgets.ts in CI
A still of the world in its AI/ML formation, captured from the high tier on a machine with a GPU (POSTER_TIER=high npm run capture-poster)

A real-time whiteboard on my own CRDT engine, with zero lost edits under network faults

A real-time collaborative whiteboard on a CRDT engine I wrote, for people editing the same board at once.

Held edit-to-remote p95 at 47 ms for 50 editors, against a 300 ms target, and under target to about 150 editors, by fanning edits out through Redis.

SDEIn progress

Edit-to-remote p95, 50 editors
47 ms
Baseline: 300 ms design target
Concurrent edits measured until applied on every other replica, 2 server nodes sharing Redis and Postgres on one Apple M5 (results/scale.json); p95 stays under 300 ms to about 150 editors and breaks between 150 and 200
Line chart of Tandem's edit-to-remote p95 latency by editors on one board: 12 ms at 20 editors, 47 ms at 50, 186 ms at 150, crossing the 300 ms target between 150 and 200, and 938 ms at 300