Third-year CS student at Osmania University, Hyderabad. I build distributed systems, ML inference pipelines, and open source tools — from scratch, with real benchmarks. I read Stripe and Cloudflare engineering blogs for fun.
I'm a third-year Computer Science student at Osmania University, Hyderabad — obsessed with building systems that are fast, correct, and resilient under pressure.
I don't reach for libraries when I can understand fundamentals by building them. Hand-rolled HNSW vector indexes. Atomic rate limiters. ML inference at 71K RPS. These aren't side projects — they're proof of depth.
I contribute to open source at production-grade repos like LangChain4j and linkedin/cruise-control, study from Stripe and Cloudflare blogs, and grind competitive programming.
Fraud detection sits directly in the transaction path — every millisecond of latency is friction for a legitimate customer, and every missed signal is a fraud loss. Most teams serve models in the same language they trained them in (Python), but Python's interpreter overhead makes it hard to sustain high, consistent throughput under load.
Trained an XGBoost classifier in Python on 284K credit-card transactions (0.17% fraud rate — a hard class-imbalance problem), then exported it to ONNX. A Go HTTP server loads the ONNX model and serves predictions, removing Python from the hot path entirely while keeping the ML tooling where it's strongest.
| Layer | What it adds | Win |
|---|---|---|
| Imbalance handling | scale_pos_weight vs SMOTE, compared | PR-AUC 0.87, recall +6% |
| Threshold tuning | Cost-based optimization (0.41 vs default 0.5) | ₹650 saved per 57K rows |
| ONNX export | Cross-language model serving | Python dropped from hot path |
| Batching | 1 goroutine owns the session, 32 max / 5ms wait | 5.67x avg batch size |
| LRU cache | FNV-1a hash, 2s TTL | 99% hit rate, ~500x latency drop |
| Hot-swap | atomic.Pointer[modelBundle] | Zero-downtime deploys |
| A/B routing | Two live model bundles, traffic-split by % | Real canary deployments |
| Drift detection | Welford's online stats per feature | Catches data drift in flight |
Most student ML projects stop at "trained a model, got X% accuracy." Sentinel goes further into the serving problem — the part that actually matters in production: latency under load, safe deploys, live experimentation, and monitoring for silent failure modes like data drift.
Distributed consensus is one of the genuinely hard, foundational problems in systems engineering — it's the reason MIT's graduate distributed systems course (6.824) uses building Raft as its flagship assignment. Three nodes need to agree on a replicated, ordered log and stay consistent even when nodes crash, restart, or the network partitions — with zero external dependencies, no consensus library to lean on.
Implemented Raft (Ongaro & Ousterhout, 2014) entirely in pure Python stdlib — the same algorithm behind etcd (which powers Kubernetes), CockroachDB, and Consul. Every piece — leader election, log replication, crash-safe persistence, and the fault-injection tests that verify all of it — was built from scratch, not delegated to a library.
| Bug | Root Cause | Fix |
|---|---|---|
| Stalled re-election | Lock held across blocking network calls — node couldn't respond to incoming votes during its own election attempt | Release lock before making network calls: 3,000+ms → 5.9ms re-election, 7/8 → 8/8 success rate |
| Stale-read race | Client queried nodes in fixed order, ignoring last-known leader — could hit a follower mid-replication or a dead old leader | Client now prefers last-known leader first, falls back across cluster |
Real screenshots from an actual running 3-node cluster — not mockups. Together they show a healthy cluster, a write committing, the leader crashing mid-session, and the data still being there once a new leader takes over.
Reads can hit any node, including followers, so a read can be slightly stale mid-replication — production Raft systems solve this with "read index" or lease-based reads. No log compaction/snapshotting yet — the log grows unbounded, a natural next extension.
Every modern RAG stack leans on a vector database — Pinecone, Weaviate, Qdrant — treating approximate nearest-neighbor search as a solved, opaque dependency. Vektr asks what's actually inside that black box by building the HNSW index (Malkov & Yashunin, 2018) — the same algorithm those products run — entirely from scratch, plus a hybrid retrieval layer on top of it.
A Java server hosts a hand-rolled HNSW graph (M=16, efConstruction=200) alongside a from-scratch BM25 inverted index. A Python microservice handles embedding. Queries run through both indexes in parallel — dense HNSW search and sparse BM25 keyword scoring — then Reciprocal Rank Fusion merges the two ranked lists without ever needing to normalize their differently-scaled scores.
| Component | What it does | Why it matters |
|---|---|---|
| HNSW Index | Hand-rolled multi-layer graph, greedy descent + beam search | recall@10 = 0.984 on 1,000 vectors |
| BM25 Index | Inverted index, k1=1.5, b=0.75 | Catches exact keyword matches dense retrieval misses |
| Reciprocal Rank Fusion | 1/(60+rank_dense) + 1/(60+rank_bm25) | Combines dense + sparse without score normalization |
| QueryCache | LRU + ReadWriteLock, 10K entries | Cache hits return in <1ms |
| HyDE rewriting | Embeds a hypothetical LLM answer instead of the raw query | Closes the question-space vs answer-space embedding gap |
| Index persistence | Atomic write-to-tmp + rename (LevelDB/RocksDB pattern) | Index loads from disk in <15ms on restart |
Most RAG projects wire together existing vector DB SDKs. Vektr instead demonstrates the algorithm underneath them — hybrid retrieval, query rewriting, and durable persistence — built and benchmarked from first principles rather than configured from a managed service.
Deploying LLMs locally requires quantization to fit consumer hardware, but nearly every published benchmark of these trade-offs targets NVIDIA GPUs — leaving Apple Silicon developers guessing which framework and quantization level to actually use.
Built two automated Python harnesses: one measuring generation speed and peak memory across 180 runs (3 models × 2 frameworks × 2 quantization levels × 5 prompts × 3 repeats), and one measuring task accuracy across another 180 runs (15 questions per configuration — math, factual recall, and code graded by actually executing the generated function against real test cases).
| Bug | Root Cause | Fix |
|---|---|---|
| Inflated llama.cpp memory readings | mmap-based model loading counted reclaimable file pages as active memory | Disabled mmap (--no-mmap) for true resident-memory measurement |
| Missing GGUF speed data (90 rows) | llama-cli writes stats directly to the terminal, bypassing Python's subprocess capture | Added --simple-io flag to route output through stdout |
Llama-3.2-3B and Phi-3.5-mini used ~10.5GB of memory at both 4-bit and 8-bit quantization — nearly identical, despite a 2x difference in weight precision. Verified by inspecting each model's runtime context-window value directly: Llama's default context (79,872 tokens) is 2.4x larger than Qwen2.5-3B's (32,768), which explains the memory gap far better than quantization does.
Most student ML work stops at "I benchmarked X." This is a full empirical research cycle — hypothesis, controlled experiment, real bugs diagnosed and fixed mid-study, a verified (not assumed) causal mechanism, and a published, citable, peer-reviewable artifact with a permanent DOI.
I respond to every message — usually within 24 hours.