Vansh Gupta - Full-Stack & AI Systems Engineer. Engineering Production Systems with precision.

Architecting robust software systems by combining low-latency backend engines with modern web runtimes. Specialized in serverless frameworks, automated data pipelines, and machine learning model integrations that solve real-world problems at scale.

Engineering
Worldview

I treat code not as the end goal, but as a mechanism to guarantee runtime stability, boundary isolation, and deterministic execution across distributed environments.

Process & Security Isolation

Zero inbound open ports via outbound polling in LUNAR, and strictly sandboxed multi-process Electron bridges validated with Zod in Lumen.

Deterministic & Graph Systems

Inductive counterparty contagion modeling over 4,002,354 edges with GraphSAGE in CrediGraph, and pure polynomial heuristic allocation with zero jitter in BuddyUp.

Edge Runtimes & Concurrency

Sub-350ms cached proxies in Cloudflare Workers, O(log n) min-heap scheduling in HyperThread OS, and race-condition-free atomic state in PostgreSQL and MongoDB.

Education

B.E. Information Science
& Engineering

The National Institute of Engineering, Mysuru

Timeline: 2024 - 2028

Capability Matrix

Explore technology capabilities mapped directly to verified execution evidence.

Languages

Java

Primary language for DSA practice, with knowledge of OOP, Strings, JDBC, AWT, Swing, and Servlets.

[UNLINKED]

Python

Backend scripting and simulation services (Flask).

[02 ALPHAENGINEX][03 CREDIGRAPH][05 LUNAR][07 HYPERTHREAD OS]

TypeScript / JavaScript

Full-stack typed applications; browser, server, and desktop runtimes.

[01 NIEDGE][02 ALPHAENGINEX][04 BUDDYUP][06 LUMEN][07 HYPERTHREAD OS][OS OPEN SOURCE]

Low-level system logic & memory structures coursework.

[UNLINKED]

Frontend

React.js

Component-driven UI architecture for web and desktop applications.

[02 ALPHAENGINEX][04 BUDDYUP][06 LUMEN][OS OPEN SOURCE]

HTML5 / CSS3

Semantic markup and styling fundamentals for web applications.

[01 NIEDGE]

Progressive Web Apps (Service Workers)

Offline-first client caching and request interception.

[01 NIEDGE]

Backend

Flask

Python web framework; layered Blueprint architecture for scalable API services.

[02 ALPHAENGINEX]

REST APIs

Standard HTTP contract design for client-server data exchange.

[01 NIEDGE][02 ALPHAENGINEX]

Cloudflare Workers

Edge serverless runtime for API proxying and web scraping.

[01 NIEDGE]

Cheerio (Web Scraping)

Server-side DOM parsing for extracting structured data from HTML sources.

[01 NIEDGE]

Concurrency & In-Memory Caching

Thread-safe concurrent execution pools and high-throughput memory caching.

[03 CREDIGRAPH]

Desktop & Application Architecture

Electron

Multi-process desktop application framework with sandboxed renderer isolation.

[06 LUMEN]

Win32 API (ctypes)

Low-level Windows OS subsystem integration for direct process, display, and hardware interaction.

[05 LUNAR]

IPC Architecture

Inter-process communication bridges routing all privileged operations through Zod-validated contracts.

[06 LUMEN]

Zustand

Partitioned client state management across isolated stores to prevent cross-store re-render thrashing.

[06 LUMEN]

Zod

Runtime schema validation for IPC contracts and type-safe API boundaries.

[04 BUDDYUP][06 LUMEN]

Drizzle ORM

Type-safe SQL ORM for structured local database operations.

[06 LUMEN]

Databases & Cloud

PostgreSQL / Supabase

Relational database schemas, Row-Level Security, and atomic stored procedures.

[04 BUDDYUP]

MongoDB Atlas

Aggregations & atomic document mutations for concurrent trading operations.

[02 ALPHAENGINEX]

SQLite

Embedded relational database for offline-first local persistence.

[05 LUNAR][06 LUMEN]

MySQL

Relational schemas, normalizations & index tuning.

[UNLINKED]

Firebase

Auth, Realtime DB, and Firestore for authentication and live data sync.

[01 NIEDGE][02 ALPHAENGINEX]

Graph Systems & Relational Exposures

Large-scale network edge modeling, k-hop neighborhood extraction, and graph data structures.

[03 CREDIGRAPH]

Machine Learning & AI

Machine Learning & Graph Neural Networks

Supervised soft-voting ensembles, PyTorch Geometric SAGEConv networks, and tabular models.

[03 CREDIGRAPH]

Unsupervised Anomaly Detection

Isolation forests and domain-engineered forensic behavioral signals.

[03 CREDIGRAPH]

Groq API

Ultra-low-latency LLM inference API for AI-powered features.

[02 ALPHAENGINEX][04 BUDDYUP][05 LUNAR][07 HYPERTHREAD OS]

Ollama

Local LLM runtime for privacy-first offline AI inference.

[06 LUMEN]

LLM Streaming (NDJSON/SSE)

Buffered token streaming from LLM endpoints with paced client-side rendering.

[06 LUMEN]

Prompt Engineering

Structured prompt design for reliable, scoped, and grounded LLM outputs.

[06 LUMEN]

Tools & Platforms

Git / GitHub

Version control and collaborative code management.

[01 NIEDGE][02 ALPHAENGINEX][03 CREDIGRAPH][04 BUDDYUP][05 LUNAR][06 LUMEN][07 HYPERTHREAD OS]

Vitest & Invariant Testing

Automated unit and invariant test suites ensuring mathematical bounds and stability.

[04 BUDDYUP][OS OPEN SOURCE]

Linux CLI

Command-line system administration and development tooling.

[01 NIEDGE][02 ALPHAENGINEX][06 LUMEN]

NPM / Postman / Wrangler CLI

Package management, API testing, and serverless edge deployment tooling.

[01 NIEDGE]

Vercel / Streamlit / Render / Railway

Static rendering and server hosting platforms.

[01 NIEDGE][02 ALPHAENGINEX][03 CREDIGRAPH][04 BUDDYUP][07 HYPERTHREAD OS]

systems BUILT

Dossier Index

01 Problem

Students faced slow portal loading speeds, frequent downtime, and lack of mobile offline access to schedules and academic records.

02 Architecture

Next-gen static frontend with Progressive Web App (PWA) client service workers, communicating with serverless Cloudflare Workers acting as API routing gateways and scraping nodes.

Implementation Approach: Built a decoupled system with an ultra-lightweight client scraping the portal through a serverless backend proxy, coupled with offline-first client storage.

EDGE PROXY & CACHE TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Decoupled edge-scraped pipeline with client-side Service Worker caching and serverless Cloudflare Workers API gateways.

Plate 1.1: NIEdge Responsive Student Dashboard & Offline PWA Portal

Technologies Used

HTMLCSSJavaScriptFirebaseCloudflare WorkersCheerioService Workers

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceChose Firebase for instant authentication and database updates. Used Cheerio for parsing DOM responses directly inside edge functions rather than spinning up full headless browsers (Puppeteer), saving significant memory and execution costs.

Constraints & AlternativesRejected operating dynamic browser engine instances (Puppeteer/Playwright) inside cloud containers due to startup time penalties and CPU footprint limits.

Cost / TradeoffCheerio relies on stable portal HTML structure. Changes to the university portal UI require backend regex/selectors updating, but the extreme latency drop made this trade-off worthwhile.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceCloudflare Workers distribute the scraping traffic globally. Serverless architecture scales automatically to handle spike hours during grade releases without infrastructure maintenance.

Constraints & AlternativesDecoupled static client views from edge database requests, caching data at local service workers.

Cost / TradeoffCaching volatile user credentials requires high-security encryption. Session tokens are encrypted in client storage using AES-256 with key management handled via sandboxed environments.

Caching Performance Story

Reduced load times from 8.2s (standard portal) to 350ms on subsequent visits by serving data directly from local caches and pre-fetching in the background.

Observed load-time comparison (NIEdge visit paths)~8.2s vs. <350ms

Origin-Dependent Route (Initial Fetch)~8,200ms

Local/Cached Route (Subsequent Visits)<350ms

Origin RouteInitial Scraping Fetch

~8.2s

Cached RouteLocal SW Cache Read

<350ms

Timeline visualization represents proportional execution latency bounds (cached route requires at most approximately 4.27% of the 8.2s reference path).

04 Measurable Outcomes

Served 1,900+ users and 35,000+ page views with a full-stack academic platform, using a serverless Cloudflare Workers API gateway and Cheerio-based scrapers to securely sync real-time college portal data.
Shipped an offline-first PWA with Service Workers for instant asset caching, plus a sandboxed in-browser programming playground that lets students run code without a backend.

System Verification Metrics

Adoption

1,900+ users

More than 1,900 users served by NIEdge during its release lifecycle.

Reach

35k+ total views

More than 35k total views recorded/reported for NIEdge.

05 Access Links

Live Demo

Dossier Index

01 Problem

Standard paper-trading platforms either lag behind real markets or crash under heavy transaction volumes due to database lock contentions.

02 Architecture

Layered backend (Flask Blueprints) isolating HTTP request handling from business validations and database repositories, rendering on a dynamic React client.

Implementation Approach: Engineered a custom trading engine that simulates real-time price volatility and executes atomic, multi-document stock purchases without write lock timeouts.

CONCURRENT MATCHING ENGINE TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Layered Flask architecture coordinating real-time volatility modeling with atomic MongoDB transactions and rate-limited order execution.

Plate 2.1: Alpha Engine X Live Trading & Portfolio Dashboard

Technologies Used

PythonFlaskReact.jsMongoDB AtlasFirebaseGroq API

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceSelected MongoDB for storing complex, nested transaction histories, and used atomic operations (`$inc`, `$push`) for instant balance updates and concurrency safety.

Constraints & AlternativesRejected SQL transactions with heavy locking intervals, favoring MongoDB Atlas concurrent write performance under transaction peaks.

Cost / TradeoffChose short polling (2s intervals) over WebSockets to reduce persistent connection overhead, allowing the server to handle more concurrent requests on basic hardware.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceImplemented rate-limiting (Flask-Limiter) and IP-based request restriction to prevent API abuse, making it resilient to DDOS and transaction spam.

Constraints & AlternativesChose periodic polling intervals (2s limits) instead of persistent WebSocket connections to reduce server CPU workloads.

Cost / TradeoffSeparating repositories from services allowed swapping MongoDB mocking easily during development, reinforcing the benefits of strict clean-architecture separation.

04 Measurable Outcomes

Built a concurrent trading platform with live prices updating every 2 seconds across 15 companies, keeping trades consistent through atomic MongoDB transactions, rate limiting, and duplicate-order prevention.
Architected a layered Flask backend (routes -> services -> repositories) over a 7-collection MongoDB schema with admin audit trails, demand-driven volatility modeling, automated P&L, and brokerage fee logic.

05 Access Links

Live Demo

Dossier Index

01 Problem

Traditional counterparty credit risk models evaluate balance sheets in isolation. If a counterparty maintains strong standalone financial ratios but its key debt partners or interbank lenders face default, distress propagates across the relational network invisibly. Concurrently, fraudulent shell entities mimic legitimate accounting ratios while accumulating extreme interbank exposures on minimal network connectivity.

02 Architecture

Multi-tier Python system featuring an interactive Streamlit analytical shell, an asynchronous inference engine dispatching model evaluations in parallel via ThreadPoolExecutor, a localized NetworkX graph analysis layer extracting k-hop contagion subgraphs, and a standalone Flask microservice exposing the fraud detection pipeline.

Implementation Approach: Formulated counterparty risk as a graph representation and multi-model ensemble challenge across 100,000 counterparties and 4,002,354 weighted exposure edges. Built an inductive GraphSAGE neural network to aggregate neighbor default probabilities, ensembled it with gradient-boosted trees and linear baselines, and implemented an unsupervised Isolation Forest over 4 domain-engineered behavioral signals to flag financial implausibility.

GRAPH ML & PARALLEL ENSEMBLE TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Graph-native credit contagion and fraud detection pipeline combining PyTorch Geometric SAGEConv networks, parallel ThreadPoolExecutor model scoring, and unsupervised Isolation Forest anomaly detection.

Technologies Used

PythonPyTorchPyTorch GeometricXGBoostScikit-LearnNetworkXStreamlitFlask

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceAdopted a soft-voting ensemble (XGBoost 40%, Random Forest 30%, GNN Contagion 20%, Logistic Regression 10%) calibrated to balance non-linear tabular precision with structural network contagion signals. Chose inductive SAGEConv layers with mean aggregation rather than transductive GCNs to permit real-time scoring of novel counterparty records without complete graph retraining.

Constraints & AlternativesRejected transductive full-graph convolutions (GCN) requiring complete retraining on graph updates; selected inductive SAGEConv layers with localized 1-hop and 2-hop neighborhood extractions to enable sub-150ms real-time scoring.

Cost / TradeoffExecuting full-graph convolutions across 100k nodes during interactive requests induces prohibitive latency and memory overhead. Resolved by precomputing global node embeddings and performing localized 1-hop and 2-hop neighborhood extractions during interactive What-if stress simulations.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceGraph and tabular datasets (132MB combined) are held in memory using vectorized NumPy score stores and lightweight edge adjacency structures. Inference requests leverage a thread-safe LRU-512 cache to achieve sub-millisecond response times on repeated evaluations, scaling smoothly across concurrent analyst sessions.

Constraints & AlternativesMaintained graph adjacency structures and 132MB tabular score arrays in memory with vectorized NumPy lookups and thread-safe LRU-512 caching, avoiding distributed database overhead while delivering sub-millisecond repeated scoring.

Cost / TradeoffPredictive power in institutional risk is useless without transparent interpretability. Integrating TreeSHAP feature contribution waterfalls alongside localized graph contagion paths builds regulatory confidence, proving why an apparently solvent firm is downgraded based on structural network proximity to distressed lenders.

04 Measurable Outcomes

Engineered a graph-native credit risk platform evaluating 100,000 counterparties and 4,002,354 relational exposure edges, combining a 2-layer GraphSAGE network (0.952 AUC-ROC) with an ensemble of XGBoost, Random Forest, and Logistic Regression to quantify systemic contagion.
Architected a parallel inference pipeline using ThreadPoolExecutor and thread-safe LRU caching to drop scoring latency to sub-150ms, complemented by an unsupervised Isolation Forest detector tracking 4 custom financial fraud anomalies.

05 Access Links

Live Demo Source Code

Dossier Index

01 Problem

Hackathons and academic cohorts suffer from chaotic team formation. Solo participants pitch themselves across unstructured Discord channels, squads end up with redundant skills (e.g. four frontend developers and zero backend support), and pre-formed friend groups fear being broken up by naive matching systems.

02 Architecture

Next.js 15 App Router monolith with React 19 Server Components for data fetching, authenticated Server Actions for mutations, a pure in-memory mathematical optimizer, and managed Supabase PostgreSQL 15 enforcing tenant isolation via Row-Level Security.

Implementation Approach: Designed a constraint-satisfying optimization platform using a pure five-pass heuristic in TypeScript that balances multi-objective mathematical criteria, preserves locked friend groups, fills declared partial squad vacancies, and uses generative AI strictly downstream for read-only narrative explanation.

MULTI-OBJECTIVE OPTIMIZATION & EXPLAINABLE AI TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Constraint-satisfying team formation pipeline combining Next.js 15 Server Actions, pure deterministic 5-pass heuristic optimization, and quarantined Groq LLM narrative explainability.

Plate 4.1: BuddyUp Multi-Objective Team Formation & Cohort Management Platform

Technologies Used

Next.js 15React 19TypeScriptTailwind CSSSupabasePostgreSQLGroq APIZodVitest

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceEnforced strict zero-randomness determinism by breaking score ties using lexicographical participant ID comparison instead of Math.random(). Quarantined generative AI (Groq Qwen 27B) strictly to Layer 2 narrative synthesis with a zero-downtime deterministic fallback, ensuring the LLM never decides team membership.

Constraints & AlternativesRejected raw LLM team generation to eliminate capacity violations, hallucinated participants, and nondeterministic drift; enforced pure 5-pass TypeScript heuristic with locked friend group immutability.

Cost / TradeoffUsing a heuristic five-pass optimizer rather than an exact integer linear programming (ILP) solver trades global mathematical optimality for sub-50ms execution and predictable memory footprint, making it suitable for live hackathon check-ins.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceEngine executes in memory with O(N * M) polynomial complexity, processing 500+ participants in under a second. Database mutations run via atomic PostgreSQL stored procedures (join_team_atomic, create_team_atomic) that eliminate race conditions under concurrent registration spikes.

Constraints & AlternativesEnforced single-team membership invariants and atomic squad mutations via PostgreSQL stored procedures and Row-Level Security, preventing race conditions under simultaneous registration spikes.

Cost / TradeoffComplex social optimization requires transparent explainability. Providing objective mathematical radar scores alongside friendly narrative explanations builds user trust, while an organizer staging sandbox with real-time score delta previews prevents post-formation disputes.

04 Measurable Outcomes

Engineered a deterministic five-pass heuristic team formation engine executing in sub-50ms across four objective functions (skill diversity 35%, role satisfaction 30%, experience balance 20%, interest alignment 15%) with zero randomness and 100% auditability.
Architected a quarantined two-layer explainability pipeline combining diagnostic mathematical scorecards with Groq LLM narrative synthesis, backed by atomic PostgreSQL stored procedures, strict Row-Level Security, and 179 passing Vitest tests.

05 Access Links

Live Demo Source Code

Dossier Index

01 Problem

Traditional remote PC management tools either consume heavy background resources with commercial third-party cloud dependencies (TeamViewer, AnyDesk) or require opening dangerous inbound firewall ports with raw shell exposure (SSH/WinRM).

02 Architecture

5-tier topology with an independent supervisor daemon (lunar_host.py) auto-restarting the worker process (main.py) with exponential backoff; multithreaded HTTP MJPEG server (port 8554) with 24-byte cryptographic session tokens; and SQLite databases in WAL mode.

Implementation Approach: Built an edge-native Python agent leveraging Telegram's global encrypted infrastructure for outbound-only long-polling control, combined with Groq LLM tool-calling and two-stage interactive confirmation buttons for state-altering operations.

SECURE REMOTE DAEMON TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Asynchronous 5-tier supervisory topology providing remote Windows management via Telegram outbound polling with zero open inbound ports.

Technologies Used

Pythonpython-telegram-botGroq APIOpenCVSQLiteWin32 APIspynputpsutilasyncio

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceEnforced zero arbitrary execution by exposing 32 strongly-typed Python functions rather than an open shell. Selected outbound long polling to eliminate router port forwarding, and implemented a thread-safe dual-key Groq pool to seamlessly absorb free-tier rate limits.

Constraints & AlternativesRejected raw shell execution endpoints (cmd/PowerShell) to eliminate prompt injection and RCE attack surfaces; enforced single-user authorization gate and sandboxed filesystem isolation.

Cost / TradeoffOutbound long polling adds slight round-trip latency compared to raw WebSockets, but guarantees zero inbound attack surface and instant operation behind NAT or mobile hotspots.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceDesigned with decoupled subsystems and thread isolation: camera acquisition runs in a dedicated thread with condition-variable frame signaling, while database writes use SQLite WAL mode and mutex locks to prevent concurrency contention.

Constraints & AlternativesConfigured SQLite in WAL mode with mutex locking for audit logs and task scheduling, while isolating high-frequency camera frame streaming in memory to avoid disk I/O bottlenecks.

Cost / TradeoffHandling sensitive surveillance requires strict ephemerality: Sentinel input events reside exclusively in an in-memory ring buffer (500 entries) with alphanumeric keystroke redaction, guaranteeing awareness without disk persistence.

04 Measurable Outcomes

Built an asynchronous remote Windows management agent used daily, with modular command routing and Groq LLM tool-calling plus multi-key failover for natural-language system control and automation.
Secured it with single-user authentication, two-step confirmation gates for destructive actions, path-traversal-safe file sandboxing, and no arbitrary shell execution; added MJPEG live streaming and OpenCV camera capture.

05 Access Links

Live Demo Source Code

Dossier Index

01 Problem

Developers who want to use large language models face a choice between cloud APIs that expose private data externally and complex self-hosted setups with no premium UI. No existing tool combined local-only inference with a crafted, developer-grade desktop experience.

02 Architecture

Multi-process Electron architecture with absolute boundary separation: a Node.js Main process managing SQLite via Drizzle ORM and Ollama HTTP integration; a Preload bridge exposing typed namespaced APIs via contextBridge; a Shared Contract Layer of TypeScript types and Zod validation schemas; and a React Renderer process with seven independently partitioned Zustand stores.

Implementation Approach: Built a native Electron application communicating with a locally running Ollama server over HTTP on localhost. All conversations are stored in a local SQLite database. No cloud backend, no telemetry, no remote API calls.

ISOLATED MULTI-PROCESS TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Offline-first desktop architecture with strict contextBridge IPC boundaries between the sandboxed UI and privileged Main process.

Plate 6.1: Lumen Local AI Chat Interface & Streaming Engine

Technologies Used

ElectronReactTypeScriptZustandDrizzle ORMSQLiteZodVite

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceEnforced Main/Renderer process separation via contextBridge to prevent RCE attack surfaces. All IPC channels follow typed namespace contracts: window.api.chat, window.api.models, window.api.database, window.api.settings, with Zod validation at both process boundaries.

Constraints & AlternativesRejected direct Node.js exposure to the Renderer process. Enforced absolute boundary separation via contextBridge; the Renderer cannot access the shell, file system, or native modules directly.

Cost / TradeoffAll UI-to-database operations require async IPC serialization, adding a slight round-trip cost. Process boundary separation prevents direct Node.js access from the Renderer, so every persistence call crosses the IPC boundary.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceState is partitioned across seven independent Zustand stores to prevent wide re-render cycles. SQLite runs in WAL mode with a 5000ms busy timeout, enabling concurrent read access alongside active write transactions.

Constraints & AlternativesPlaced all SQLite persistence exclusively in the Main process rather than the Renderer, preventing UI thread blocking during database transactions and avoiding bundler dependency compilation risks.

Cost / TradeoffDecoupling token streaming from direct state binding (using a buffered queue drained by a character-level animation engine with adaptive backlog handling) eliminates layout recalculations during active LLM output and maintains stable 60 FPS rendering.

04 Measurable Outcomes

Designed a secure multi-process Electron architecture by sandboxing the renderer (contextIsolation: true, nodeIntegration: false) and routing all 17 filesystem, database, and network operations through a single Zod-validated IPC bridge, preventing renderer-level access to privileged system APIs.
Engineered a resilient local LLM streaming pipeline with adaptive exponential backoff, request abort tracking, and a partitioned 7-store Zustand architecture backed by SQLite persistence, ensuring application state remained consistent across interrupted or failed requests.

05 Access Links

Live Demo Source Code

Dossier Index

01 Problem

CPU scheduling simulators are often visual-only tools that fail to model actual microkernel safety parameters, starvation traps, or realistic performance metrics.

02 Architecture

Decoupled single-page app containing process execution state machines, feeding Gantt playback streams on the client, with FastAPI serving AI context vectors.

Implementation Approach: Developed a micro-simulation engine from scratch using TypeScript for client scheduling queues and FastAPI for Groq API orchestration.

PREEMPTIVE SCHEDULER SIMULATION TOPOLOGYSYSTEM TOPOLOGY

SELECT NODE TO INSPECT SPECS

Multi-thread simulation engine with O(log n) min-heap queues, Web Worker offload, and Groq AI narration pipeline.

Plate 7.1: HyperThread OS Control Center & Scheduling Queue Configurator

Technologies Used

FastAPIReact.jsTypeScriptPythonGroq API

03 Interesting Engineering

Engineering Decisions & Implementation Tradeoffs

Decision 01: Core System Architecture Choice

Rationale / ChoiceConstructed scheduling priority queues using custom Min-Heap arrays in TypeScript rather than standard arrays, optimizing sorting on large numbers of process injections.

Constraints & AlternativesConstructed scheduling priority queues using custom Min-Heap arrays rather than standard javascript sort algorithms to prevent CPU thread freezes.

Cost / TradeoffUsing AI narration introduces API latency. Handled this by pre-generating descriptions of the scheduling outcomes asynchronously so Gantt playback remains completely stutter-free.

Decision 02: Data Persistence & Caching Topology

Rationale / ChoiceDesigned process queues to scale up to 10,000 simulated threads without UI freeze by leveraging Web Workers for off-thread queue computations.

Constraints & AlternativesDecoupled microkernel scheduling computations from Gantt render threads using dynamic web worker message passing.

Cost / TradeoffSimulating operating systems highlights the critical importance of priority aging. Without it, low-priority process starvation is inevitable under heavy workloads.

04 Measurable Outcomes

Reduced CPU process selection complexity from O(n) to O(log n) using custom Min-Heap structures.
Modeled Ring 0/Ring 3 OS-level privileges and aging safety systems to prevent process starvation.
Integrated tick-by-tick Gantt visualization with Groq AI-narrated voiceovers.

05 Access Links

Live Demo

Contributions

Open Source Work

mantinedev/mantine

30k+ ★PR #9146 · Shipped in v9.6.3

@mantine/hooks (useThrottledCallback)

Resolved a state-locking defect in useThrottledCallback where clearTimeout permanently halted all subsequent calls. Authored Jest regression tests verifying timer reset, throttling cadence, and callback recovery.

TypeScriptReactJestReact Hooks

View Merged PR #9146

antonio-orionus/Arroxy

800+ ★3 Contributions on Main

Core Windows CI & Media Engine

Fixed Windows test failures across a 2,400+ test Vitest suite (CRLF fixtures, 8.3 short-path resolution, .cmd process wrappers), unblocking Windows CI. Implemented YouTube live stream/clip URL intent classification and reserved device name escaping (CON, NUL, AUX).

TypeScriptElectronVitestWin32 Paths

View Repository

Currently

Active Momentum

Real-time engineering cadence, repository commits, and active build benchmarks.

Resume

Academic & Professional Record

A concise record of my education, technical work, projects, and experience.

View PDF

VANSH GUPTA

B.E. Information Science & Engineering

EDUCATION

The National Institute of Engineering, Mysuru

B.E. in Information Science and Engineering (2024-2028)

Vansh Gupta - Full-Stack & AI Systems Engineer. Engineering Production Systems with precision.Engineering Production Systems with precision.

Engineering Worldview

Education

Capability Matrix

Languages

Frontend

Backend

Desktop & Application Architecture

Databases & Cloud

Machine Learning & AI

Tools & Platforms

systems BUILT

NIEdge

01 Problem

02 Architecture

EDGE PROXY & CACHE TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

Alpha Engine X

01 Problem

02 Architecture

CONCURRENT MATCHING ENGINE TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

CrediGraph

01 Problem

02 Architecture

GRAPH ML & PARALLEL ENSEMBLE TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

BuddyUp

01 Problem

02 Architecture

MULTI-OBJECTIVE OPTIMIZATION & EXPLAINABLE AI TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

LUNAR

01 Problem

02 Architecture

SECURE REMOTE DAEMON TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

Lumen

01 Problem

02 Architecture

ISOLATED MULTI-PROCESS TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

HyperThread OS

01 Problem

02 Architecture

PREEMPTIVE SCHEDULER SIMULATION TOPOLOGY

03 Interesting Engineering

04 Measurable Outcomes

05 Access Links

Open Source Work

Currently

Academic & Professional Record

VANSH GUPTA

Vansh Gupta - Full-Stack & AI Systems Engineer. Engineering Production Systems with precision.

Engineering
Worldview