Rajkumar Ahirwar

Data Analytics/Analytics Engineer

Indian Institute of Technology Kanpurinternship, freelance

Open to roles

CommunicationProblem SolvingGITLeadership

Queue Cure : Real-time queue management for clinics.

A live digital token queue for a neighbourhood clinic: a receptionist screen to add patients and call the next token, and a patient-facing waiting room screen that updates instantly — no refresh — with a wait estimate computed from that clinic's actual consultation times, not a guess. Multi-clinic: any number of clinics can use this from one deployment. Each clinic creates its own queue and gets its own private link — nothing is shared, including live updates (verified — see "Multi-clinic isolation" below). Process Why a single shared snapshot instead of separate diffs per screen Early designs for things like this often try to send minimal "patches" to each screen (e.g. "token 12 status changed to done"). That's more bandwidth-efficient, but it means each screen has to reconstruct queue state from a stream of patches — and if a screen misses one message (reconnect, tab backgrounded on a phone, flaky clinic wifi), it silently drifts out of sync forever. Sending one full, authoritative snapshot on every change is slightly more data, but it makes "out of sync" structurally impossible: a screen that reconnects gets the truth, not a delta. Results Empty queue: "Call Next" disables with a plain explanation instead of letting the receptionist click into a no-op or an error. Last patient of the day: calling next when no one is waiting still correctly closes out the current patient — it just doesn't open a new one. The button label changes to "Finish current patient" so this isn't ambiguous. No-shows: a dedicated skipped status, separate from done, so a no-show doesn't get counted as a completed consultation in the duration average (which would quietly corrupt the wait-time math). Daily reset with no cron job: every query is resets everyday Reflection Auth changed shape, too. A single-clinic PIN can live as a frontend constant and it's a minor sin (anyone with devtools can find it, but it's one clinic's one secret). That doesn't scale to N clinics — there's no single constant to bake in. So the PIN moved server-side: hashed with bcrypt at clinic-creation time, checked via a clinic:auth socket event, and the authorization lives on the socket connection, not in the browser. That's a meaningfully different trust model, not just a refactor — worth flagging because it's easy to read "added multi-clinic" as a pure UI change when it actually moved

6 media files · queuetracerfrontend-pz8z7449.b4a.runView

IPL Crunch '26: End-to-End Sports Telemetry Pipeline & Match-Winning Insights Engine

Raw IPL tracking data from over 1,200 matches is locked in deeply nested JSON files. For sports analysts, this creates a major bottleneck: standard tools drop crucial metadata or crash entirely due to inconsistent data formats across seasons. I needed to bridge this gap by building an automated Python pipeline. The goal was to clean and flatten 293,764 individual ball deliveries with zero data loss, fix formatting shifts between seasons, and instantly generate executive-ready dashboards that debunk common T20 myths for team strategists. Process I started by trying standard Pandas JSON flatteners, but they crashed or dropped the top-level match metadata entirely because the files were too deeply nested. Realizing a generic approach wouldn't work, I built a custom two-stage Python parsing loop. Stage one grabs the structural match details; stage two maps that down to all 293K individual ball-delivery rows, ensuring zero data loss. To handle variable names shifting across seasons (like "striker" becoming "batter"), I integrated a dynamic mapping layer instead of writing rigid, brittle code. Finally, I grouped the data into explicit game phases using Pandas. Instead of manually building charts, I automated everything through code to instantly export styled, executive-ready Excel ledgers. Results The custom Python ETL pipeline successfully processed 293,764 nested data points across 1,200+ match files with 100% automation and zero data loss. It completely replaced manual report compilation by instantly generating three presentation-ready assets (2 analytical trend charts and a multi-sheet structured Excel ledger). Next time, I would scale this by migrating the local script to an AWS Lambda function triggered by an S3 bucket upload, and use Apache Spark instead of Pandas to handle live, real-time match streams instead of static batch files. Reflection While the local Python pipeline works perfectly for historical files, it isn't built for a live production environment. Next time, I would move the script into the cloud by hosting the ETL code on AWS Lambda, triggered instantly whenever new telemetry is uploaded to an S3 bucket. I'd also swap Pandas for Apache Spark to handle real-time match streaming streams smoothly during live games. Finally, instead of static Excel files, I would wire the clean data core into a live Tableau or PowerBI dashboard for real-time strategy tracking.

7 media files · ipl-crunch-1-62srrcivra9wziabzqjja5.streamlit.appView

This is Rajkumar’s work on Wooble.

Build a profile that shows what you can do — and share it anywhere.

Build yours