Who is Harshit Agarwal?

Harshit Agarwal is a Fullstack Software Architect and AI Researcher based in India. He acts as Founding Engineer & Lead SDE at platforms like Famcare, shoppin', and endorphind, specializing in high-throughput backend services and deep learning systems.

What technologies does Harshit Agarwal use?

Harshit specializes in Python, FastAPI, Go, C/C++, Java, React/Next.js, Flutter, PyTorch, AWS (SageMaker, EKS, EC2), Kubernetes, Rancher, Docker, PostgreSQL, Redis, and WebSockets.

What research has Harshit published?

Harshit has published research on transformer-based NLP architectures for software vulnerability exploit prediction in NVD (AIP / Springer), and has submitted gait analysis/Parkinson's Freezing of Gait prediction research to Health and Technology.

What open-source projects has Harshit built?

Harshit is the author of gaitSetPy (a Python package for high-throughput gait time-series preprocessing and modeling) and has built custom generative video nodes for ComfyUI workflows.

Routing Infrastructure (OSRM)

We cut our routing API costs to basically zero and got sub-millisecond ETAs in the process.

Building a booking flow with live rider tracking, every active trip needs continuous ETA updates, not just one. Polling every 20 seconds for a 20 minute trip means 60+ API calls per order. Scale that across active live tracking and commercial APIs become expensive fast. For a lean team, that's not a rounding error.

So I self-hosted OSRM instead. A localized OpenStreetMap graph, just our core Whitefield region, packaged as a sidecar container sitting right next to the API service inside the same ECS task. Routing queries now run over localhost. Zero external calls, zero external bill, single-digit millisecond latency.

AWS ECS task architecture diagram showing the API container and OSRM sidecar communicating over localhost in under 2ms, with external maps APIs bypassed — **Fig. 1** — OSRM runs as a sidecar inside the same ECS task as the API. Routing never leaves the task, so there's no external call and no per-request bill.

routing API cost

<10ms

p50 latency

60+

calls/trip avoided

OSRM gives you the shortest physical route. It doesn't know Bangalore traffic exists. So I layered custom heuristics on top, time-of-day multipliers, and static penalties for the junctions every Bangalore driver already knows by name: Silk Board, Tin Factory, Kundalahalli Gate. If a route passes within 300m of one of these during peak hours, the penalty gets added before the user ever sees the ETA.

Satellite map of Whitefield, Bangalore showing traffic hotspot junctions: Tin Factory, Hoodi Circle, Hope Farm Junction, Kundalahalli Gate, and Marathahalli Bridge — **Fig. 2** — OSRM's raw shortest-path output is adjusted by a heuristic layer, time-of-day multipliers and static 300m-radius penalties at junctions like Tin Factory, Kundalahalli Gate, Hoodi Circle, and Hope Farm Junction, before the ETA is shown to the user.

And if the OSRM container ever hiccups, it falls back to straight-line distance instantly. Routing is a UX layer, not something that should ever block a booking.

Building at scale isn't about reaching for the most popular API by default. It's about knowing when self-hosting buys you control, speed, and cost savings that the commercial option simply can't match for your specific problem.

Knowing what NOT to build is just as important as knowing what to build.