Darshan Balar — Senior Backend Engineer

Work

What I've built

Production systems, real numbers.

25–30M events/day · ~2K events/sec peak

Context: Exotel, a cloud telephony platform, needed a way to trace a call's journey across its legs for internal debugging.
Approach: Architected an event-driven pipeline on Kafka feeding OpenSearch. Events are keyed by leg SID to preserve per-leg ordering, and every event carries the call SID so a full journey is a single query.
Result: End-to-end call journey tracing for engineering and support, reducing debugging time to resolution.

Go · Kafka · OpenSearch · Event-driven architecture

500 partitions · 30→200 autoscaling consumers

Context: The pipeline had to survive OpenSearch write failures, consumer crashes and redeploys without losing or duplicating call events.
Approach: Offsets are committed only after each batch fully resolves. Transient write failures are retried; events that exhaust retries go to a fallback topic that is consumed and resynced. OpenSearch document IDs are producer-assigned event IDs, so replays overwrite instead of duplicating.
Result: Duplicate-free replays after crashes, with the topic sized at 500 SID-keyed partitions to support consumer autoscaling from 30 to 200 instances.

Go · Kafka · Idempotency · Retries & fallback topics

18 data · 3 master · 3 coordinating nodes

Context: The analytics pipeline needed a search cluster under the team's own control.
Approach: Deployed OpenSearch on EKS via Helm: data nodes on i3 instances using local NVMe as persistent volumes, master state on EBS so a rescheduled master rejoins with its metadata, and a headless service for cluster discovery.
Result: 2 replicas per index; when a data node was lost, a replacement i3 node was added and shards recovered from replicas.

Kubernetes · EKS · Helm · OpenSearch · AWS

−30% end-to-end call setup latency

Approach: Redesigned cross-server call bridging, moving to direct IP calling integration between telephony servers.
Result: 30% reduction in end-to-end call setup latency.

Telephony · Distributed systems · Network architecture

−30% storage cost · −20% upload response time

Context: Duplicate image uploads at IndiaMART were inflating storage and slowing the upload path.
Approach: Designed a deduplication service using perceptual hashing that returns the existing image URL instead of storing a duplicate.
Result: 30% reduction in storage costs and 20% faster upload responses across the platform.

Go · Perceptual hashing

20M+ req/day · −30% page rendering time · −40% storage

Approach: Built a Go image-conversion service on libvips (bimg) supporting JPEG, PNG, WebP and AVIF, and led migration of 300M legacy images to WebP through a batch pipeline.
Result: Serving 20M+ requests/day; the migration cut page rendering time by 30% and image storage by 40%.

Go · libvips · Batch processing at 300M scale

Personal project

What: Real-time stock paper-trading platform: live market data over WebSockets, portfolio management, trade execution, and Redis-cached intraday price search.

Go · PostgreSQL · Redis · Docker · WebSockets