Yuvraj Suri — Full Stack Engineer

01 — About

Backend engineer who owns systems,
not just tickets.

I build enterprise backend systems that run in production with real users. My focus is Java backend architecture — Spring Boot, Servlets, REST API design, PostgreSQL — with enough frontend range to ship complete features independently.

At KocharTech I've gone beyond implementation: designing data models, solo-architecting full modules, migrating a platform to Java 21, and deploying to international production on OCI.

// What I work on

MDM systems, backend APIs, database design, and cloud deployments. I build the infrastructure other features depend on.

// Solo ownership

Desktop MDM backend and DFRM portal — both designed and shipped by me alone, not as one member of a large team.

// Background

3 years teaching advanced Mathematics (Class 11–12). Built habits of precision and structured decomposition that carry into engineering.

// Education

BCA — DAV College, Amritsar (2021–2024, CGPA: 7.40)

03 — Experience

Full Stack Engineer KocharTech · DeviceMax Dec 2024 — Present

// MDM, CPE (TR-069), DFRM, Desktop MDM

Migrated the MDM web app Java 8 → Java 21 for international deployment readiness — full API compatibility audit, deprecated API removal, regression testing across all modules before production promotion.
Designed a dynamic field storage model using Java services and PostgreSQL JSON — runtime schema extension without migrations, enabling multi-tenant configurability.
Built the DFRM portal from scratch, alone — JSP/Servlet backend, Firebase Realtime for push notifications, full event pipeline from risk detection to browser alert.
Solely designed the Desktop MDM backend API layer — device lifecycle, policy enforcement, token-authenticated device communication, audit logging. Deployed to Apache Tomcat / OCI.
Shipped MDM and CPE remote management APIs with JUnit + Mockito test coverage.

Full Stack Developer Intern KocharTech · DeviceMax Jun 2024 — Dec 2024

// Converted to full-time after 6 months

Automated global country → state → city onboarding via structured data ingestion APIs — eliminated manual setup per region entirely.
Designed a hierarchical DB model that cut user onboarding time from 2 hours → 15 seconds.
Fixed production bugs on live international deployments. Applied PostgreSQL aggregation optimizations that measurably reduced analytical query response time.

04 — Projects

// Enterprise · Solo Ownership

Desktop MDM — Backend System

"No backend existed. Devices needed enrolling, monitoring, and policy control at enterprise scale — securely and traceably."

What I Built

Complete REST API backend for a Desktop MDM system. Every layer: PostgreSQL schemas with Flyway migrations, token-authenticated device communication, policy enforcement APIs, audit logging. Containerized with Docker, deployed to OCI.

Key Challenge

Working on an existing production MDM database — no clean slate. Every schema change had to be backward-compatible with live data across other modules. Flyway migrations were essential for controlled, versioned evolution without breaking sibling modules.

github.com/yuvrajsuri

API Sample — Policy Enforcement

POST /api/mdm/device/policy/apply

// Request
{
  "deviceId": "DEV-7821-XC",
  "policyType": "LOCK_SCREEN",
  "config": {
    "pinRequired": true,
    "timeoutSeconds": 300
  },
  "token": "Bearer eyJhbGci..."
}

// Response 200 OK
{
  "status": "POLICY_QUEUED",
  "deviceId": "DEV-7821-XC",
  "auditId": "AUD-20241215-0042",
  "appliedAt": "2024-12-15T10:23:41Z"
}

JavaSpring BootPostgreSQLFlywayDockerToken AuthApache TomcatOCI

✦ 0 → production — sole architect and implementer
✦ Full audit trail on every policy event for enterprise compliance
✦ Schema versioned via Flyway; safe for shared production DB

// 0→1 Build · Real-Time

DFRM Portal

"Device financing ops needed a risk-monitoring dashboard with live alerts — built from zero."

What I Built

Full DFRM web portal — JSP/Servlet backend, PostgreSQL data layer, Firebase Realtime for push notifications. Sole designer and implementer.

API Sample — Risk Query

GET /api/dfrm/risk/device/{deviceId}

// Response 200 OK
{
  "deviceId": "DEV-4421",
  "riskScore": 82,
  "riskLevel": "HIGH",
  "flags": ["MISSED_PAYMENT",
           "LOCATION_ANOMALY"],
  "notified": true
}

JSP/ServletsJavaPostgreSQLFirebase Realtime

✦ Real-time push notifications — risk events surfaced instantly
✦ Built solo; live in international financing workflows

// Hackathon · AI Integration

Code-Wand — Traveler Risk Intelligence

"No fast, intelligent way for travelers to assess geo-political risk at a destination."

What I Built

Location-aware risk platform with Google Gemini LLM for contextual news analysis and safety scoring. JWT-authenticated REST APIs, Spring Boot backend, React frontend.

API Sample

POST /api/risk/analyze

// Request
{ "location": "Kabul, AF",
  "travelDate": "2025-02-10" }

// Response
{ "riskScore": 91,
  "riskLevel": "EXTREME",
  "aiInsight": "Active conflict..." }

Spring BootJavaReact.jsPostgreSQLGemini LLMJWT

✦ LLM-enriched risk scoring per destination
✦ Shipped end-to-end within hackathon timeframe

// Platform Engineering · International Deployment

MDM Platform — Java 8 → Java 21 Migration

"The core MDM product was on Java 8, blocking international deployment, security compliance, and long-term maintainability."

What I Did

Full platform migration across all DeviceMax modules — MDM, CPE, DFRM, Desktop MDM. Audited every deprecated/removed API, replaced legacy patterns, validated behavior across modules, then promoted to Apache Tomcat / OCI production.

Java 8 → 21Spring BootApache TomcatOCIJUnit / MockitoMulti-module

✦ Full platform on Java 21 — LTS, security compliant, internationally deployable
✦ Zero regression in live MDM operations post-migration
✦ Unlocked modern Java API adoption across all DeviceMax modules

05 — Architecture

How Desktop MDM Works

Each hop in the MDM flow has a distinct responsibility — authentication, command dispatch, policy resolution, and acknowledgment. Here's the full device-to-policy pipeline:

01 · Client

Managed Device

Windows/Linux endpoint. MDM agent polls server for pending commands on a heartbeat interval.

→

HTTPS + Token

02 · Auth

API Gateway

Token validation on every request. Invalid or expired tokens rejected before touching business logic.

→

REST API

03 · Core

Backend Service

Spring Boot service. Handles enrollment, policy resolution, command queuing, and audit event emission.

→

SQL + JSONB

04 · Data

PostgreSQL

Device registry, policy configs (JSONB), command queue, audit log — versioned schema via Flyway.

→

ACK

05 · Response

Policy Applied

Device receives payload, applies policy, sends ACK. Audit record updated. Admin console reflects status.

Key constraint: The Desktop MDM database wasn't a fresh instance — it was the existing shared production MDM PostgreSQL DB, live with data from CPE and DFRM. Every schema change had to be backward-compatible. This made Flyway non-negotiable and required understanding the full system, not just the Desktop MDM slice.

06 — Engineering Decisions

The choices that separated this work from basic CRUD — and the reasoning behind each one.

// PostgreSQL · JSONB Columns

Why store dynamic device fields as JSONB instead of separate schema tables?

MDM serves multiple clients with different custom fields per device. Separate tables per field would mean:

A migration + deployment per new field request
Schema sprawl across client-specific tables
No runtime configurability without engineer involvement

JSONB columns allowed clients to define custom fields at runtime with no schema changes. PostgreSQL's native JSON operators still allow indexing and querying on specific keys — no meaningful performance trade-off.

// Token-Based Auth

Why token auth for device-to-server communication instead of sessions?

MDM devices are headless — no human to re-enter credentials. Session-based auth breaks here:

Sessions require stickiness or shared storage across server nodes
Devices may go offline for hours; sessions expire
Token validation is stateless — any node validates without shared session state

Token auth lets devices authenticate independently per heartbeat, scales horizontally, and embeds device identity + permissions in the payload.

// Flyway Migrations

Why Flyway instead of raw SQL scripts for schema management?

The critical constraint: I was working on the existing shared production MDM database — not a fresh DB I owned. The same instance was live for CPE and DFRM modules. Raw SQL scripts would mean:

No version history — impossible to know what was applied where
Risk of re-running on production
No coordination across modules on the same schema

Flyway gave versioned, sequential, checksum-verified migrations — every Desktop MDM change trackable and safe to apply to the shared production DB.

// Hierarchical DB Model

Why redesign onboarding as a hierarchical relational model?

Original international onboarding required manually adding country → state → city per region — a 2-hour manual process per deployment. Flat storage meant repeated lookups and no relational integrity.

A hierarchical FK-linked model (country → state → city) with a bulk ingestion API meant: one API call, structured JSON in, normalized hierarchy out. Result: onboarding time dropped from 2 hours → 15 seconds.

Yuvraj
Suri.

Backend engineer who owns systems,
not just tickets.

Desktop MDM — Backend System

DFRM Portal

Code-Wand — Traveler Risk Intelligence

MDM Platform — Java 8 → Java 21 Migration

Smart India Hackathon

Office Hackathons (2024–2025)

NCC Navy — 'B' Certificate

Mathematics Instructor — 3 Years

Let's build
something real.

YuvrajSuri.

Backend engineer who owns systems,not just tickets.

Desktop MDM — Backend System

DFRM Portal

Code-Wand — Traveler Risk Intelligence

MDM Platform — Java 8 → Java 21 Migration

Smart India Hackathon

Office Hackathons (2024–2025)

NCC Navy — 'B' Certificate

Mathematics Instructor — 3 Years

Let's buildsomething real.

Yuvraj
Suri.

Backend engineer who owns systems,
not just tickets.

Let's build
something real.