Backend Engineer | Scalable APIs, automation & agentic AI systems | NIT Bhopal M.Tech

leetcode

github

Rishabh Jain  • Peerlist

I built a CLI tool that generates accurate subtitles for any video in under 2 minutes. Here's what I learned the hard way. The problem: existing subtitle tools either cost money, require uploads to third-party servers, or produce timestamps that drift out of sync with the video. I wanted a fully local, offline-capable pipeline. Achieved ~94% word accuracy on clear audio using Whisper medium model with no internet dependency after setup. The interesting decision: Whisper outputs word-level timestamps but they aren't always aligned with natural sentence boundaries — it'll split "I don't" across two subtitle cards, which looks jarring. I wrote a post-processing pass that merges short segments using a sliding window over character count and pause duration thresholds, then reformats to SRT. This alone made the output feel professional rather than machine-generated. Batching was the other challenge — processing a 90-minute video as one chunk causes memory spikes. I chunked audio into 30-second overlapping windows and merged transcripts with deduplication on the overlap region. What I'd do differently: add speaker diarization using pyannote.audio so multi-speaker videos get proper speaker labels in the subtitles. That's the one feature that would make this genuinely production-grade. Full case study on my portfolio → my-portfolio-one-zeta-50.vercel.app

AutoSubAI - CLI Subtitle Generator

I built a real-time collaborative code editor (think Google Docs for code) in 6 weeks. Here's what I learned the hard way. The problem: building real-time sync sounds simple until two users edit the same line simultaneously. Naive "last write wins" causes one user's changes to silently vanish — the worst possible UX in a collaboration tool. Achieved stable multi-user sync with zero conflict data loss in testing across 10 concurrent users. The interesting decision: I implemented Operational Transformation (OT) lite — not the full Google Docs algorithm (that's 50,000 lines of engineering) but a simplified version that handles the most common conflict patterns: concurrent inserts at the same position and concurrent deletes of overlapping ranges. The key insight was that most real collaborative editing conflicts are positional, not semantic — if you correctly transform cursor positions after every remote operation, the document stays consistent. WebSocket room management was the other hard part — when a user disconnects mid-edit, you need to flush their pending operations before removing them from the room or their last keystrokes disappear. What I'd do differently: I'd use CRDTs (Conflict-free Replicated Data Types) instead of OT from the start. OT requires a central server to order operations; CRDTs are peer-to-peer and scale better. I only understood this after building the OT version. Full case study on my portfolio → my-portfolio-one-zeta-50.vercel.app

Codecast - Real-Time Collaborative Code Edito

Built a distributed task queue system in Python here's what I learned. Most developers think of a web API as the place where work happens. It's not. It's where work gets *accepted*. The real insight behind distributed task queues: → Accept the request instantly → Return a task ID → Do the heavy lifting in the background → Let the client poll for results Here's the stack I used: FastAPI — lightweight HTTP layer that just enqueues and returns RabbitMQ — message broker with priority queue support (0–10) Celery — worker orchestration across 2 replicas × 2 concurrent slots Redis — result backend with no TTL (results persist indefinitely) Flower — real-time monitoring dashboard The architectural decisions that mattered most: task_acks_late: True Workers only acknowledge a task AFTER completing it — not when they pick it up. If a worker crashes mid-job, the message goes back to the queue. Zero data loss. worker_prefetch_multiplier: 1 Each worker holds exactly one task at a time. No hoarding. This makes autoscaling predictable — spin up a new worker, it immediately takes load. Priority queues RabbitMQ supports x-max-priority. High-priority jobs jump the queue without any special routing logic. The result? An API that stays responsive at 1ms response times while workers handle jobs that take minutes — and survives worker crashes without losing a single task. If you're building ML inference, video processing, or any long-running computation — you don't need a bigger server. You need this pattern.

Distributed Task Queue

I built a real-time crypto trading platform. Here's what  I learned the hard way. The problem: most trading demo projects fake real-time with polling. I wanted actual event-driven order execution — where a market event  triggers a chain of services without any service directly calling another. The result: sub-100ms order acknowledgment latency with zero dropped events  under concurrent load testing. The interesting decision: I chose Redis PubSub over WebSocket broadcasting  for inter-service communication. WebSockets felt natural but created tight coupling — every service needed to know about every other. Redis as a message bus let each service be completely unaware of its consumers. When I added the notification service later, I plugged it in without touching a single existing service. That's when event-driven architecture stopped being a concept and became a tool I actually understood. I also had to design idempotent order handlers from scratch — when a Redis message gets redelivered after a crash, you cannot process the same order twice. Solved it with a Redis SET-based deduplication layer keyed on order UUID. What I'd do differently: I underestimated schema design for the order book. I normalized too aggressively early on and paid for it with expensive JOIN queries on the hot path. I'd denormalize the order state table from day one and use PostgreSQL LISTEN/NOTIFY instead of polling for order status updates. Full case study on my portfolio → my-portfolio-one-zeta-50.vercel.app

NovaTrade - Real-Time Trading Platform

I built a VS Code agent that reviews your code like a senior engineer in 4 weeks. Here's what I learned the hard way. The problem: LLM code review tools send your entire file to the model and return a wall of comments. Developers ignore walls of comments. I wanted diff-aware review — only flag what actually changed, with context of what it changed from. Pull request review time in my own projects dropped by ~40% once I started using it myself. The interesting decision: diff-based prompting was harder than it sounds. Raw git diffs are noisy — they include whitespace changes, import reorders, and unrelated refactors that confuse the model. I built a diff preprocessor that strips structural noise and reconstructs semantic context windows around each changed chunk before sending to Gemini. The review quality jumped significantly compared to naive diff injection. I also had to solve streaming — users won't wait 8 seconds for a review to appear. Gemini's streaming API returns tokens progressively; piping that through the VS Code extension API into an output channel gave it the "typing in real time" feel that makes it usable. What I'd do differently: I'd add a review memory layer — right now each review is stateless. A model that remembers "you always forget null checks in this codebase" would be 10x more useful than one that starts fresh. Full case study on my portfolio → my-portfolio-one-zeta-50.vercel.app