Backend Software Engineer
I build reliable APIs, integrations and production systems that handle real-world complexity.
Backend-focused Software Engineer with 3+ years of experience building scalable APIs, middleware systems, integrations, and data pipelines using Node.js, TypeScript, MongoDB, SQL, Redis, and AWS.
I own features end-to-end — from requirement discussions through implementation, testing, deployment and production support — across backend services, distributed workflows, databases, third-party integrations and full-stack applications.
- CURRENT
- Software Development Engineer (SDE-I)Univo Education Pvt Ltd · Feb 2025 — Present
- PREVIOUSLY
- Full Stack DeveloperNoidaSe Digital · Feb 2023 — Feb 2025
Hover or focus a stage to read what it does.
CLIENTApplications calling one stable contract instead of six external ones.
APIThe contract clients depend on. Routing, authentication, rate limits.
MIDDLEWAREValidation, mapping and transformation, centralized in one deployable unit.
CACHEA cheaper copy of an expensive answer. Buys latency, costs staleness.
DATABASEIndexes and access patterns set the latency floor for everything above.
EXTERNAL SERVICESUseful, and outside your control. Timeouts and retries are the entry fee.
The shape of the systems I work on — client to system of record, with the integrations that make it complicated.
Engineering snapshot
3+
Years of experience
Backend-focused, across two product teams
20K+
API requests / day
Processed and routed by the LSQ → Salesforce middleware
10K+
Leads / day
Lead-generation funnel contributed to on the admissions platform
Node.js
BACKEND RUNTIME
REST APIs, middleware architecture, background jobs, API integrations.
MongoDB
DATA LAYER
Indexing strategies, aggregation pipelines, query and schema tuning.
AWS
CLOUD
S3 and IAM for secure file storage, access control and document workflows.
Five systems, and what each one had to survive.
Every problem, decision and number below is drawn from the CV. Pick a project to walk its architecture layer by layer, or open the full case study.
Lead Synchronization Middleware
A middleware platform that keeps lead data consistent between LSQ and Salesforce behind one unified API.
20,000+API REQUESTS ROUTED DAILY
- PROBLEM
- Lead data had to move reliably between LSQ and Salesforce, and transformation logic lived in the frontend — coupling client applications to the payload shape of each external system.
- APPROACH
- A middleware platform in Node.js and MongoDB exposing a unified API layer, with centralized mapping, validation and transformation pipelines behind it.
- RESULT
- 20,000+ API requests processed and routed daily with high availability, and integrations that can be switched through endpoint configuration alone.
- Node.js
- MongoDB
- REST APIs
- Caching
- Grafana
- Salesforce API
LSQ
Lead source. Lead records enter the middleware through the unified API layer instead of being transformed inside client applications.
How I think about systems.
A request path, annotated. Each layer states what it does, when it earns its place, and what it costs — because every layer costs something. This section is a point of view rather than a claim about any one project.
Request
- WHAT IT DOES
- An inbound call from a client, a partner system or a scheduled job. The unit of work everything downstream is measured against.
- WHEN IT EARNS ITS PLACE
- Always. The useful question is which requests are read-heavy, which are write-heavy, and which are allowed to fail.
- WHAT IT COSTS
- Treating every request as equal means the expensive ones set the shape of the whole system.
SEEN INLead Synchronization Middleware
Where the systems were built.
Two roles, three years, one direction of travel: from full-stack product delivery into backend and integration ownership.
FEB 2025 — PRESENT
CURRENT
Software Development Engineer (SDE-I)
Univo Education Pvt Ltd
Middleware services, integration pipelines and production ownership.
- Built and maintained fault-tolerant middleware services processing 20k+ daily requests, with retry workflows, monitoring and automated failure recovery.
- Designed scalable request pipelines to route, validate, transform and synchronize data between Salesforce and multiple third-party platforms.
- Took ownership of backend features from requirement discussions through implementation, testing, deployment and production support.
- Node.js
- MongoDB
- Salesforce
- AWS
- Cron Jobs
- Grafana
FEB 2023 — FEB 2025
Full Stack Developer
NoidaSe Digital
Production web applications, lead workflows and AI-assisted product features.
- Developed and maintained multiple production-grade web applications using Next.js, React, Node.js and MongoDB for client-facing and internal business platforms.
- Built lead management workflows and backend APIs that captured user data and synchronized leads with external CRM systems, enabling automated sales and customer engagement processes.
- Designed and implemented an AI-powered text chatbot using OpenAI APIs and retrieval-augmented generation (RAG), delivering context-aware responses from custom knowledge bases.
- Next.js
- React
- Node.js
- MongoDB
- OpenAI
- Module Federation
EDUCATION
B.Tech, Computer Science EngineeringAKTU · 2019 — 2023
What I work with, and how it connects.
Not a logo wall. These are the technologies listed on my CV, grouped by the job they do — and wired to the ones they actually get used with.
Hover or focus a technology to see what it connects to.
BACKEND
07Where most of the work happens
DATABASES
05Data layer and query behaviour
PERFORMANCE
05Behaviour under load
CLOUD & DEVOPS
06Getting it deployed and keeping it there
ENGINEERING
07Practices carried across both roles
OTHER
04What the work above adds up to.
These are not quotes from my CV. They are the principles the work on this page represents — each one stated alongside the implementation it is read from.
- 01
Build for failure, not for the happy path
Integration calls fail transiently. The interesting design question is not whether a request succeeds, but what the system does on the attempt that doesn't.
DRAWN FROM
Retry mechanisms, failure recovery workflows and automated failure recovery in the LSQ → Salesforce middleware.
- 02
Keep integrations replaceable
Third-party systems get swapped. If mapping and transformation live behind one contract, replacing a provider is a configuration change rather than a rewrite of every client.
DRAWN FROM
A unified API layer that let frontend applications switch integrations through endpoint configuration alone.
- 03
Measure before optimizing
Dashboards and error rates decide what gets worked on. Optimizing the path you assumed was slow is how effort gets spent without moving anything.
DRAWN FROM
Grafana dashboards and application monitoring used to detect 5xx failures and performance bottlenecks in production.
- 04
Prefer the simplest architecture that scales
Caching a hot GET endpoint and indexing the query behind it solves more real load than a more elaborate design usually does — and there is less of it to operate.
DRAWN FROM
Caching on frequently accessed endpoints, plus indexing and aggregation tuning, on a service routing 20,000+ requests daily.
- 05
Observability is part of the system
A service you cannot see into is a service you cannot operate. Logs, metrics and alerts ship with the feature, not after the first incident.
DRAWN FROM
Observability work with DevOps — logs, metrics and monitoring alerts feeding production stability and incident response.
Have a system worth building?
I’m interested in backend-heavy full-stack roles, scalable systems, infrastructure-aware product engineering, and technically challenging problems.