Systems Delivered

Production Systems With Clear Engineering Trade-offs

Each system is framed by the operational problem, architecture, data flow, technical decisions, scaling path, and outcome. Employer and client systems are presented generically.

MiniMiner PoW Lab

View Project

Problem Statement

Blockchain concepts are often explained abstractly, making it difficult to show wallets, pending transactions, mining rewards, Proof-of-Work difficulty, validation, and tamper detection without connecting to real cryptocurrency networks.

Architecture Overview

React and Vite browser application with Zustand state management, localStorage persistence, Recharts benchmark visualization, crypto-js SHA-256 hashing, and an optional C++ WebAssembly mining engine with JavaScript fallback.

Data Flow Explanation

Users create simulated wallets, submit validated transactions into a pending pool, mine pending transactions plus a SYSTEM reward into blocks, and inspect the resulting chain through explorer, validation, benchmark, and tamper-detection flows.

Engineering Decisions

Core blockchain behavior was kept in dedicated modules for blocks, hashes, transactions, wallets, mining, validation, and simulation import/export. Balances are derived from confirmed chain data instead of trusted as mutable wallet fields.

Scaling Strategy

Mining runs in bounded batches and yields control back to the browser so the interface remains responsive. Difficulty is intentionally capped from 1 to 5, and the WebAssembly miner is optional so the JavaScript fallback keeps the app portable.

Outcome

Produced an educational portfolio system that makes Proof-of-Work, nonce search, mining rewards, chain validation, tamper detection, and benchmark behavior visible without mining real cryptocurrency.

Travel Planning Product System

View Project

Problem Statement

A journey-planning product needed destination discovery, itinerary creation, cost estimation, and multi-step planning flows without making the interface feel fragmented.

Architecture Overview

TypeScript application architecture with structured domain views for destinations, itinerary entities, cost inputs, and planning workflows.

Data Flow Explanation

User planning inputs are translated into itinerary state, combined with destination and cost data, then presented as a coherent journey plan that can evolve across multiple screens.

Engineering Decisions

TypeScript was used to keep product state and UI contracts explicit. Planning workflows were separated from presentation components to avoid locking business rules inside screens.

Scaling Strategy

The product model keeps itinerary, destination, and estimation concerns separated so additional regions, pricing rules, and planning steps can be added without rewriting core flows.

Outcome

Showed product engineering around multi-step planning, user-owned data, and typed frontend architecture.

High-volume E-commerce Platform

View Project

Problem Statement

High-volume catalog discovery, cart behavior, flash offers, order tracking, and mobile-first browsing needed to remain responsive under promotional traffic.

Architecture Overview

Flutter mobile client, Node.js API services, PostgreSQL product and order data, Redis caching, object storage for media, Dockerized deployment on AWS.

Data Flow Explanation

The app reads catalog snapshots through paginated APIs, resolves pricing and availability through backend services, writes cart and order events through transactional endpoints, and receives order updates through push and polling fallbacks.

Engineering Decisions

Flutter supported consistent UI performance across devices. Node.js fit high-concurrency API workloads. Redis reduced repeated catalog and offer reads, while PostgreSQL kept transactional order integrity.

Scaling Strategy

Catalog endpoints were cached by segment, media was moved behind CDN-ready storage, order writes were isolated from browsing traffic, and slow queries were profiled around filters and promotions.

Outcome

Improved browsing responsiveness by up to 30% and reduced release cycle overhead through repeatable build and deployment pipelines.

Modular CMS Platform

View Project

Problem Statement

Small professional websites needed dynamic page management, reusable content sections, a simple admin workflow, and deployment compatibility with constrained hosting environments.

Architecture Overview

Laravel application with JSON-based page sections, PHP backend rendering, admin-managed content, and shared-hosting-aware deployment assumptions.

Data Flow Explanation

Admin users manage structured page sections, the CMS stores those sections as page configuration, and the frontend renders reusable blocks from the saved content model.

Engineering Decisions

Laravel provided routing, persistence, and admin workflow primitives quickly. JSON section configuration kept the CMS flexible without overbuilding a large page-builder system.

Scaling Strategy

Reusable section definitions reduce page-specific code, while the constrained deployment model keeps the system practical for low-cost hosting and small business sites.

Outcome

Produced a public CMS foundation for modular business websites with practical admin controls and deployment-aware architecture.

Real-time Field Operations System

View Project

Problem Statement

Operational teams required live visibility into distributed field activity, status transitions, alerts, and mobile updates across unstable network conditions.

Architecture Overview

React Native mobile surface, Node.js backend, WebSocket channels, PostgreSQL persistence, Redis pub/sub, and Docker-based cloud deployment.

Data Flow Explanation

Field events are persisted through APIs, broadcast through real-time channels, acknowledged by clients, and reconciled through periodic state refreshes when connectivity drops.

Engineering Decisions

WebSockets handled low-latency updates while REST endpoints preserved deterministic recovery. Redis decoupled event fan-out from database writes.

Scaling Strategy

Event streams were partitioned by operational scope, reconnection logic was hardened, and hot status reads were cached to reduce database pressure.

Outcome

Delivered real-time operational visibility with resilient fallback behavior for intermittent mobile networks.

Multi-role SaaS Marketplace

View Project

Problem Statement

A marketplace needed multi-role workflows, service discovery, booking logic, payments-adjacent flows, and admin operations without collapsing into one large application layer.

Architecture Overview

Flutter mobile app, Django backend, PostgreSQL relational model, role-based APIs, admin dashboards, Docker deployment, and CI/CD release flow.

Data Flow Explanation

Users discover services, submit requests, update booking states, and trigger notifications through API workflows guarded by role and state transition rules.

Engineering Decisions

Django accelerated secure admin and relational workflow development. Flutter enabled shared mobile delivery while repository boundaries kept feature logic isolated.

Scaling Strategy

Service search and booking queries were indexed, admin operations were separated from user-facing paths, and deployment automation reduced manual release work.

Outcome

Supported marketplace operations across customer, provider, and admin roles with a maintainable SaaS foundation.

Telemetry Monitoring System

View Project

Problem Statement

Teams needed reliable mobile visibility into metrics, alerts, and device or service state without overloading the backend with repeated refresh traffic.

Architecture Overview

Flutter client, Node.js APIs, time-series style event storage, PostgreSQL metadata, Redis cache, alert workers, and cloud services.

Data Flow Explanation

Telemetry enters ingestion endpoints, is normalized into event records, summarized for dashboards, and pushed to mobile clients through alert channels.

Engineering Decisions

The architecture separated ingestion, summary reads, and notification delivery so spikes in telemetry would not block dashboard usage.

Scaling Strategy

Aggregated views reduced raw event scans, caches protected common dashboard queries, and background workers handled alert evaluation.

Outcome

Created a stable monitoring surface with clearer alert delivery and reduced redundant polling from mobile clients.

Distributed Systems Monitoring Experiment

View Project

Problem Statement

A microservices environment needed baseline observability, load testing, and a research path toward intelligent scaling decisions.

Architecture Overview

Python-based experimental services with Prometheus metrics collection, Grafana dashboards, Locust load testing, and a foundation for RL-based autoscaling research.

Data Flow Explanation

Services expose runtime metrics, Prometheus collects system behavior, Grafana visualizes pressure points, and Locust generates repeatable load patterns for scaling experiments.

Engineering Decisions

The experiment separates workload generation, telemetry capture, dashboarding, and scaling research so each part can be measured and changed independently.

Scaling Strategy

Baseline load profiles and metrics create the feedback loop needed for future autoscaling policy work and capacity experiments.

Outcome

Established a public distributed-systems lab for monitoring, load behavior, and intelligent scaling research.

Location Tracking System

View Project

Problem Statement

Operational users needed location updates, trip or task state, route visibility, and recovery from inconsistent GPS and network availability.

Architecture Overview

React Native or Flutter mobile clients, Node.js APIs, geospatial data in PostgreSQL, background location processing, and cloud deployment.

Data Flow Explanation

Driver location updates are validated, persisted, and projected into route status views consumed by rider and admin clients.

Engineering Decisions

Location writes were kept lightweight. Route projections were separated from raw location events to make client reads predictable.

Scaling Strategy

GPS updates were throttled, route views were cached, and background workers handled cleanup and trip state transitions.

Outcome

Delivered practical real-time tracking with controlled write volume and predictable mobile map behavior.

Event Operations Platform

View Project

Problem Statement

Event teams needed registration, attendee operations, schedule updates, notifications, and admin workflows across mobile and backend surfaces.

Architecture Overview

Flutter mobile app, Django APIs, PostgreSQL, admin console, notification services, and CI/CD deployment.

Data Flow Explanation

Attendee actions flow through authenticated APIs, update event records, and trigger notifications or admin-visible state changes.

Engineering Decisions

Django offered strong admin primitives and relational integrity, while the mobile app kept event workflows modular and reusable.

Scaling Strategy

High-read event data was cached, registration paths were protected with transactional checks, and deployment automation reduced release friction.

Outcome

Enabled reliable event operations with mobile-first access and structured administrative control.

Residential Operations System

View Project

Problem Statement

Residential operations required occupancy tracking, billing support, resident records, request handling, and admin controls in a reliable system.

Architecture Overview

Flutter or web mobile surface, Django backend, PostgreSQL database, role-based access, reporting views, and Dockerized deployment.

Data Flow Explanation

Resident and room records are managed through authenticated workflows, operational requests move through status transitions, and reporting views summarize occupancy and activity.

Engineering Decisions

A relational backend fit the operational domain. Clear permission boundaries prevented admin, staff, and resident workflows from mixing.

Scaling Strategy

Indexed occupancy and billing queries, modular workflow services, and repeatable deployment helped the system remain maintainable as records grew.

Outcome

Delivered structured hostel operations with clearer data ownership and fewer manual coordination points.

Webpage Monitoring Automation

View Project

Problem Statement

Manual checks for listing or page changes were slow, repetitive, and easy to miss, especially when users needed fast notification without staring at a browser.

Architecture Overview

Python automation service with page-fetching logic, change detection, scheduled checks, Telegram alerts, Gmail notification support, and local configuration for monitored targets.

Data Flow Explanation

The monitor fetches configured pages, normalizes the relevant content, compares the latest snapshot against previous state, and sends notifications when meaningful changes are detected.

Engineering Decisions

Python kept the automation compact and practical. External notification channels were separated from page monitoring logic so alert delivery could evolve without rewriting the watcher.

Scaling Strategy

The monitoring loop can add targets through configuration, tune polling intervals by page importance, and isolate notification failures from the core change-detection path.

Outcome

Produced a practical automation tool for real-time webpage change alerts with clear separation between fetching, comparison, state, and notification delivery.

GraphQL React Application

View Project

Problem Statement

A full-stack application needed typed frontend data flow, reusable API contracts, and a clearer way to request nested data without over-fetching or scattering REST calls across screens.

Architecture Overview

TypeScript GraphQL server and React client using Apollo-style data flow, schema-defined operations, typed queries, and component boundaries around API state.

Data Flow Explanation

React views request data through GraphQL operations, the server resolves domain fields through typed contracts, and Apollo client state feeds the UI with predictable loading and error paths.

Engineering Decisions

GraphQL was used to make frontend data needs explicit. Typed operation boundaries helped prevent accidental contract drift between the client and server.

Scaling Strategy

Schema ownership, query structure, and reusable client hooks create a path for adding features without expanding ad hoc endpoint sprawl.

Outcome

Showed full-stack API architecture with typed data contracts, frontend integration, and maintainable GraphQL client/server boundaries.

Commerce MVP

View Project

Problem Statement

A focused commerce product needed product discovery, cart state, order submission, and cash-on-delivery handling without overbuilding marketplace or enterprise commerce complexity.

Architecture Overview

TypeScript web application with product listing views, cart state management, checkout flow, order capture, and simple fulfillment assumptions around cash-on-delivery orders.

Data Flow Explanation

Users browse products, add items to cart state, submit checkout details, and create an order record that can be handled through an operational fulfillment workflow.

Engineering Decisions

The MVP kept commerce behavior narrow: product browsing, cart flow, and order creation. This allowed the system to validate the buying workflow before adding heavier payment or inventory infrastructure.

Scaling Strategy

The architecture leaves room for inventory checks, payment gateways, admin order handling, and catalog filtering once the core product flow is proven.

Outcome

Delivered a lean commerce foundation that shows practical product browsing, cart behavior, and order workflow design.