Computer Science & Engineering
AI / ML  ·  Backend  ·  Systems  ·  Scientific Computing

   

Software is strata. People touch the surface; almost nobody sees the scheduler, the lock, the migration or the trace beneath it. That lower layer is where I work — and this page descends through it.

I'm a B.Tech Computer Science & Engineering student at Lovely Professional University, building toward backend engineering, systems and applied AI/ML.

I'm drawn to the part of software that has to be right rather than merely visible: shared state under contention, a pipeline fed by unreliable sources, a service that should refuse a dangerous configuration instead of trusting that nobody will ask for one. I like taking an idea through data, experiment, implementation and validation — and then writing down why it works, next to the code that makes it work.

Everything below links to a repository, a file or a pull request. If a claim can't be pointed at, it isn't here.

Split the way my portfolio splits it: what has shipped in a public repository, and what I use but haven't shipped yet.

Three repositories I own. Each figure animates something the code actually does.

A deadlock simulator and concurrency visualiser.  _{Go · Next.js · TypeScript · WebSockets · Docker · MIT — sole author}

A Go engine runs every simulated process as its own goroutine, competing for shared resources. Each request is applied tentatively, checked with the Banker's algorithm, and committed or rolled back; when a circular wait closes, the engine finds the cycle and recovers by terminating a victim. A Next.js client renders the resource-allocation graph live over a WebSocket bridge.

• A short critical section. The safety check copies the allocation matrices under the mutex and releases it before its O(P²·R) search, so the expensive part never blocks other goroutines — banker.go#L15-L30
• No recursion in cycle detection. An explicit-stack DFS with white/grey/black colouring, which reconstructs the cycle itself from the stack — detection.go
• Tests assert state, not success. A granted request must move Available, Allocation and Need to exact values; CI runs go mod verify, the Go suite and a frontend build on every push — scenarios_test.go · ci.yml
• A stress mode. NIGHTMARE=1 releases a thundering herd — 50,000 processes against 5,000 resources — and logs heap and GC behaviour as it runs — nightmare.go

Repository slazyverse/deadlockd ↗︎  ·  Architecture runtime flow ↗︎  ·  Run it docker compose up starts the Go engine and the Next.js client together.

A satellite air-quality platform for India.  _{Python · FastAPI · PostgreSQL / PostGIS · Streamlit · Docker — team project; the platform layer is mine}

Surface AQI, formaldehyde (HCHO) hotspots and active-fire monitoring over India, estimated from satellite observations — Sentinel-5P TROPOMI, MODIS aerosol optical depth, ERA5 reanalysis — with CPCB and OpenAQ ground stations as reference. It was built against the ISRO Bharatiya Antariksh Hackathon 2026 problem statement; inside the codebase it is called VAYU-DRISHTI.

What I built: the backend foundation, its live-data API layer and the GIS dashboard — the platform the team's science runs on and is read through.

• Fails at import, not in production. The settings model refuses DEBUG=True alongside ENVIRONMENT=production; the misconfiguration raises before the app can accept a request — config.py
• One trace ID per request. Middleware binds a request ID into structlog's context, so every log line carries it and the caller gets it back as X-Request-ID — main.py
• One database driver. Alembic runs migrations through asyncio and create_async_engine, so asyncpg serves runtime and migrations alike — and every dependency carries a line saying why it is there — requirements.txt
• A dashboard with honest states. Streamlit and Folium pages for surface AQI, HCHO hotspots, fire monitoring, forecasts, explainability and reports, each with explicit loading, empty and error states — dashboard/

What teammates built: the data-collection and ML pipeline (Yeshika), and the AQI calculation, Earth Engine ingestion and Random Forest baseline (Soumyadeb). State: in progress — a research pipeline and platform, not an operational air-quality service.

The layer underneath.  _{Next.js 16 · TypeScript · Three.js / React Three Fiber · Tailwind v4 · Vitest · Playwright — sole author}

A portfolio built as a cross-section rather than a page. A procedural WebGL city is the way in; beneath it the site descends through interface, engine and substrate, following one real deadlockd request from the click down to the four lines of Go that decide whether it is safe.

• Claims are typed. A Claim cannot be constructed without a Source pointing at the file that proves it, so the honesty rule is enforced by the compiler — types.ts
• Evidence is tested. A CI suite fetches every cited source and fails the build if a link dies or a quoted excerpt drifts from the file it quotes — evidence.test.ts
• Budgets are gates. Initial JavaScript has a hard 200 KB gzipped ceiling checked in CI; the WebGL layer is split out and loaded only after capability probes — check-budget.mjs
• Contrast is asserted. A test parses the design tokens and checks every text–surface pairing against WCAG AA, alongside axe checks in Playwright — contrast.test.ts

Live sagar-tailor-portfolio.vercel.app ↗︎  ·  Repository slazyverse/portfolio ↗︎

Repositories owned by other people, where I built a defined part. Kept separate from my own work on purpose.

The interface moves around the system; the system is the thing underneath. GitHub renders images, not runtimes, so this is only a preview — the interactive version, a WebGL descent through one real request and a Banker's algorithm you step through by scrolling, lives on the portfolio ↗︎.

I like problems where the obvious layer is not the interesting one.

A race condition nobody noticed.
A dataset that rejects the clean assumption.
A model that looks correct until you test it.
An API that works locally and fails under load.
A system that only becomes elegant once its architecture is understood.

These are the principles I've taken from that kind of problem, each linked to the code where it was practised:

Directions I'm actively working in — not credentials.

• Data structures & algorithms — slazyverse/leetcode is set up to record accepted Java solutions automatically, with pattern notes, complexity references and progress statistics generated from the solutions themselves.
• Backend & real-time systems — deeper Go concurrency, state synchronisation over WebSockets, and services that are observable by default.
• Applied AI / ML — moving from the platform around models to the models themselves: feature pipelines, evaluation, and honest error analysis.
• Scientific & geospatial data — satellite and instrument archives, and pipelines that keep their provenance.
• System design — the trade-offs behind an architecture, written down before it is built.

_{Coursework: Data Structures & Algorithms · Object-Oriented Programming · Programming in Java — iamneo × LPU  ·  certificates}

_{Rendered every six hours from the public contribution calendar by a workflow in this repository — no third-party stats service.}

If you're working on systems, data infrastructure or research software — or you've found something wrong in one of my repositories — I'd like to hear about it.

Portfolio ↗︎  ·  LinkedIn ↗︎  ·  GitHub ↗︎