Skip to content
Vinod Kumar PeddiSoftware Engineer
Section 1 of 7: Intro
Software Engineer · EverUptimeFull-stack · Backend · Distributed systems

Software engineer building full-stack products and the backend systems behind them — queues, ledgers, access control — designed to stay correct under load, failure and time.

Scroll
01Selected work
Payments · Distributed systems
  • Node.js
  • Express
  • PostgreSQL 15
  • Redis 7
  • BullMQ
  • React
  • Vite
  • Docker Compose
AChallenge

Consistency under failure

Payment state has to agree across the merchant dashboard, the customer's checkout session and an asynchronous engine — while a simulated bank injects latency and failures.

BSolution

Queue, idempotency, retry

Idempotency keys reject duplicate transactions. A Redis job queue decouples request latency from processing. Webhooks retry with exponential backoff up to five attempts, and refunds — partial or full — reconcile against the ledger.

Payment Orchestrator

A Stripe-style payment gateway with an asynchronous processing engine, resilient webhooks and idempotent APIs.

Payment Orchestrator case study
02Selected work

Five systems, five different problems.

  1. 01 Payment Orchestrator
  2. 02 Event-Driven Analytics
  3. 03 Exam Seating Management
  4. 04 Multi-Tenant SaaS Platform
  5. 05 GrillBot
02CQRS · Event-driven architecture

Event-Driven Analytics

An e-commerce analytics backend that separates writes from reads with a transactional outbox and RabbitMQ.

CQRS · Event-driven architecture
AChallenge

The dual-write problem

Committing a database write and publishing an event are two operations. If either fails on its own, the read side silently drifts from the write side.

BSolution

Transactional outbox

Events are written to an outbox table in the same transaction as the business data, then relayed to RabbitMQ — at-least-once delivery. Idempotent consumers absorb duplicates via a processed_events table, and poison messages land in a dead-letter queue.

  • Node.js
  • Express
  • amqplib
  • RabbitMQ 3
  • PostgreSQL 14 ×2
  • Docker Compose
Pattern
CQRS · transactional outbox · materialized views
Guarantees
At-least-once delivery · idempotent consumers · DLQ
Services
command :8080 · consumer · query :8081
03Full-stack product · Web + mobile

Exam Seating Management

A web and mobile platform for exam scheduling, seat allocation, faculty assignment and attendance tracking.

Admins schedule exams, manage rooms and blocks, assign invigilators and send automated emails. Faculty and students get their own web and React Native dashboards with allocations, attendance and notifications. Bulk student uploads run through Python validation, and system issues open ServiceNow incidents automatically.

  • React
  • React Native
  • Node.js
  • Express
  • MongoDB
  • Python · openpyxl
  • ServiceNow
  • JWT · RBAC
Full-stack product · Web + mobile

From the live product

Exam Seating Management admin dashboard, faculty allocation and login screensExplore project
Roles
Admin · Faculty · Student
Surfaces
Web dashboards · React Native apps
Integrations
Email automation · ServiceNow incidents · Excel import
04SaaS · Access control

Multi-Tenant SaaS Platform

A role-based multi-tenant platform where every query is scoped to a tenant and every route to a role.

Super admins manage tenants; tenant admins manage users, projects and tasks inside their tenant; users get read-only access. Subscription plans cap users and projects. Migrations and seeds run on container start so the system is usable immediately.

Roles and what they can touch

01Platform

Super admin

  • View tenants
  • View plans and limits
  • Read tenant projects, users or tasks
02One tenant

Tenant admin

  • Dashboard
  • Create projects and tasks
  • Manage users within plan limits
  • See other tenants
03One tenant

User

  • Dashboard
  • View projects and tasks
  • Write anything

Every request, in order

SaaS · Access control

Identity from the JWT, then role, then tenant — each enforced by middleware before a controller runs, so isolation cannot be forgotten in a query.

Roles
Super admin · Tenant admin · User
Isolation
Tenant middleware · per-route RBAC
Limits
Plan-based caps on users and projects
  • Node.js
  • Express
  • PostgreSQL
  • JWT
  • React · Vite
  • Tailwind CSS
  • Docker Compose
05AI product · Mock interviews

GrillBot

AI mock interviews: generated questions, recorded answers, automated feedback.

GrillBot generates interview questions with the Gemini API for a chosen role, stack and experience level, lets candidates record answers with the camera on or off, and returns rated, per-question feedback.

  • Next.js
  • Node.js
  • Express
  • MongoDB
  • Gemini API
  • Clerk
  • Tailwind CSS
AI product · Mock interviews
AI
Gemini API question generation and feedback
Auth
OAuth + JWT

More systems

Smaller, sharper problems.

Focused services and products, each documented and runnable. Tap a row for what it does, then open the source.

70+ public repositories on GitHub

03Engineering experience

Where the work happened.

2026

EverUptime

01 / 05

Orbit · tap a marker

2026EverUptime
  1. ExperiencePresentNowIncident managementUptime monitoringOn-call

    EverUptime

    Software Engineer

    Current role. EverUptime is an end-to-end incident management and observability platform for developers, DevOps and SREs — uptime monitoring and on-call management built to minimise downtime.

    About the company
  2. Systems work2025 — 20266+ systemsAll containerisedDocumented READMEs70+ public repos

    Independent systems work

    Distributed systems · payments · SaaS

    A run of production-shaped backend systems, each containerised and documented: payment orchestration, CQRS analytics, event-driven order processing, multi-tenant SaaS, real-time monitoring.

    • Payment Orchestrator — Redis/BullMQ engine, idempotency keys, webhooks with backoff, refund ledger
    • Event-Driven Analytics — CQRS with transactional outbox, RabbitMQ, idempotent consumers, DLQ
    • Node.js
    • PostgreSQL
    • Redis
    • RabbitMQ
    • Docker
    • Next.js
    • TypeScript
    On GitHub
  3. Experience2025CSA · CAD certifiedScoped appsFlow automationACLs · RBAC

    ServiceNow

    ServiceNow Developer Intern · Remote

    Platform engineering on ServiceNow: scoped applications, automated workflows and access control on top of a governed data model.

    • Developed scoped applications with App Engine Studio and Script Includes
    • Built Service Catalog items, Record Producers and Workflows to automate service requests
    • ServiceNow
    • App Engine Studio
    • Flow Designer
    • Script Includes
    • ACLs
    • JavaScript
  4. ExperienceDec 2024 — Jan 2025JWT + OAuth authREST integrationMongoDB · MySQL

    Technical Hub

    Full Stack Developer Intern · Surampalem, Andhra Pradesh

    Built interactive, responsive web applications end to end: React front ends, Node.js APIs and MongoDB / MySQL data layers.

    • Implemented authentication and authorization with JWT and OAuth
    • Integrated RESTful APIs between front end and back end
    • HTML
    • CSS
    • JavaScript
    • React
    • Node.js
    • MongoDB
    • MySQL
    • JWT
  5. Education2022 — 2026CGPA 8.4300+ LeetCode100+ GfG12 certifications

    Aditya Engineering College

    B.Tech, Information Technology · Surampalem, Andhra Pradesh

    CGPA 8.4. Foundations in data structures, operating systems, networks and databases — and the start of building real systems outside coursework.

    • 300+ problems on LeetCode, 100+ on GeeksforGeeks
    • Certifications across ServiceNow, Cisco networking and JavaScript, Pearson IT Specialist, NPTEL cloud and IoT
    • C
    • C++
    • Java
    • SQL
    • DBMS
    • OS
    • Networks
04Systems & technology

Not a list of logos. A map of decisions.

Every node is tied to a system I built with it. Tap or hover one to see where — and what it connects to.

Software engineering

Where it was usedidle

Tap a technology to see where it was used — or a system to see its stack.

01Frontend
02Backend
03Data
04Infrastructure
05Systems
05How I think

Engineering principles

Performance

Fast systems should feel fast.

01APIs return 202 and hand work to a queue; reads come from materialized views, not joins.

Reliability

Assume the network fails. Then design.

02Acknowledgements, retries with backoff, idempotent consumers, dead-letter queues.

Scalability

Decouple, so each part can grow alone.

03Workers scale horizontally behind a broker; the API never waits on the bank.

Observability

If it isn't measured, it isn't done.

04Health endpoints that check every dependency; structured logs with the ids that matter.

Security

Every route has a role. Every tenant has a wall.

05JWT identity, per-route RBAC and tenant middleware — enforced in one place, not remembered in many.

Simplicity

If it fits in one diagram, it will ship.

06Small services with clear contracts; one docker-compose up from clone to running system.

06About

Boring underneath. Effortless on top.

Most of what I build lives below the surface — the ledger that has to balance, the queue that has to drain, the permission check that has to hold. I've spent the last few years learning exactly how those pieces fail: duplicate messages, half-finished writes, retries that double-charge. So I design the failure path first, write it down, and put a product on top that never has to think about it.

Today I'm a Software Engineer at EverUptime, working on incident management and uptime monitoring — software whose entire job is to notice when other software breaks. Before that: a ServiceNow internship, a full-stack internship at Technical Hub, and a run of production-shaped systems on GitHub — a payment orchestrator, an event-driven analytics pipeline, a multi-tenant SaaS platform.

Local time

IST

Based in

Andhra Pradesh, India

Now

EverUptime

Tap a card to expand

profile.manifest.yaml
09

What I do

Three kinds of work I keep coming back to.

  1. 01

    Backend & distributed systems

    Payments, event pipelines, tenant-scoped platforms. Idempotency keys, outbox tables, durable queues, RBAC — the patterns that keep a system correct when a message arrives twice or a process dies mid-write. Node.js, TypeScript, PostgreSQL, Redis, RabbitMQ.

  2. 02

    Full-stack products

    React and Next.js on top of those systems: checkouts, dashboards, admin tools, a mobile companion. Fast first paint, keyboard-friendly, honest loading states — the product should feel lighter than the machinery underneath it.

  3. 03

    Reliability & platform

    Containerised, documented, observable. Health checks, structured logs, one command from clone to running, and on-call workflows that keep incidents short — the same discipline I bring to uptime monitoring at EverUptime.

Field notes

Short lessons from building.

Design decisions written down after they were made — each one links to the repository where it lives.

Tap a note to open it

Distributed systems01

Publish after commit is the bug

Writing to the database and then publishing to the broker looks fine until the process dies in between. The outbox table turns two operations into one transaction; a relay does the publishing later, and idempotent consumers make the inevitable duplicates harmless.

Event-Driven Analytics
Backend02

Idempotency is the cheapest insurance

A unique constraint on an idempotency key is a few characters of SQL. Without it, every retry — from a client, a broker, a load balancer — is a potential double charge or double order. Design the key into the contract, not into a hotfix.

Order Processor Service
APIs03

202 Accepted and a durable queue

Ingestion endpoints don't need to finish the work; they need to promise it. Validate, publish to a durable queue with persistent messages, return 202. Reject malformed messages without requeue; nack transient failures so they come back.

User Activity Service
Payments04

Webhooks are a retry problem

The merchant's endpoint will be down at the worst moment. Delivery has to be its own job with exponential backoff and an attempt cap, and it must never sit in the request path of the payment itself.

Payment Orchestrator
Real-time05

Snapshot, diff, broadcast

When the upstream can't push, poll it into a snapshot and diff against the last one with a pure function. Pure means testable: added, modified, deleted, and mixed cases become table-driven tests instead of manual checks.

Real-Time FTP Monitor
AI systems06

Classify, then respond

A small fast model labels intent with a confidence score; a larger model answers as the matching expert. Below a 0.7 threshold the system asks instead of guessing — cheaper, faster and more honest than one giant prompt.

LLM Prompt Router
07Connect

Email

Local time

IST

Andhra Pradesh, India

Currently

Software Engineer at EverUptime

Always up for a conversation about systems, products, and the hard parts in between.

Elsewhere