Open to SDE-1 backend roles — India or remote

Systems that keep their promises when everything arrives at once.

I'm a software engineer at Netradyne, where my job is backend quality and test automation — API suites for our microservices, root-cause analysis through the service and data layers, regression tooling. Finding those failures made me want to design against them instead, so I've built three production-shaped backends in Java and Spring Boot on my own time. This site is the evidence.

Automation → backend Java · Spring Boot · Kafka · PostgreSQL · Redis Anywhere in India · open to remote

Built on my own time — three case studies

01 / 02 / 03

2+

years as a software engineer at Netradyne, on backend quality and automation

250+

bugs found pre-release by tracing failures through service and data layers

60%

less manual effort after I automated the API regression workflow

3

backends designed, built and documented end to end, outside work hours

01 — Projects

Three backends, built to close the gap

My day job is finding where services fail. These are my attempt at the other chair — designing the seams properly instead of discovering them in a bug report. Each one is built around a specific failure mode, and each case study is about that failure rather than the feature list. All three are personal projects, not production systems, and the write-ups say so.

Case 01 — Payments

Payment Gateway & Ledger Service

A Razorpay-inspired gateway built around a payment lifecycle state machine — created, captured, settled, refunded — where every transition is recorded in an audit trail and every outbound event leaves through a transactional outbox rather than a second network call inside a database transaction.

Spring BootKafkaPostgreSQLRedisAES-GCM
Read case study
The hard part
A customer clicks pay twice. A Redis-backed idempotency filter locks the request key and replays the stored response, so the second click gets the first charge's answer instead of a second charge.
Also inside
A PCI-inspired card vault with envelope encryption and tokenization, plus a Redis Lua rate limiter.

Case 02 — Distributed systems

Distributed AI App-Builder Platform

A Lovable-inspired platform that turns a prompt into a running app. Spring Cloud handles discovery, config and gateway routing; Spring AI drives code generation with tool-calling and RAG-style context injection; Kubernetes provisions a live preview pod per build, with MinIO for artifacts and Redis for caching.

Spring CloudEurekaGatewaySpring AIKubernetesMinIO
Read case study
The hard part
A build that half-succeeds across four services. Kafka with a Saga pattern and idempotent consumers means a failure part-way through unwinds cleanly instead of leaving a pod running and a record claiming it isn't.
Also inside
Dynamic pod allocation for previews, with artifact sync and cache warming.

Case 03 — Concurrency

Hotel Booking & Dynamic Pricing

An Airbnb-inspired booking backend with JWT auth, Stripe payments and a pricing engine built on the decorator pattern — surge, seasonality and occupancy each wrap the base rate, recomputed hourly by a scheduled job rather than on every read.

Spring BootSpring SecurityJWTPostgreSQLStripe
Read case study
The hard part
Two guests booking the last room at once. JPA pessimistic locking with atomic bulk inventory updates makes the second request wait, then fail honestly, rather than overselling the room.
Also inside
Decorator-based pricing rules that can be composed without touching the booking path.

02 — About

Two years learning exactly where backends break

Let me be straight about where I am. I joined Netradyne in July 2024 as an Associate Software Engineer and was promoted to Software Engineer within six months. Netradyne builds fleet safety systems — telemetry streaming off vehicles on the road, turning into alerts a fleet manager acts on. When an alert is wrong, someone stops trusting the product.

My work there is backend quality and automation, not feature development. I write the API test suites for the Speeding V2 microservices, debug the Alert Geofence module end to end through REST endpoints, database queries and event flows, and I built the automation that replaced our manual API regression pass. It's a job spent reading other people's services closely enough to find what they got wrong.

I want the other chair. Not because testing is beneath me — because two years of it taught me what careless design actually costs, and I'd rather be the one making those calls than the one filing them. So I've built three backends on my own time, each one aimed at a failure mode I've watched cause real damage: a charge that fires twice, an event that never leaves the service, inventory sold to two people at once.

I also don't think the automation background is a detour. Most production bugs aren't in the logic somebody wrote — they're in the seams between services, where a retry wasn't planned for or two writes were supposed to be one. Finding those for a living is decent preparation for building things that don't have them.

What I'm after is an SDE-1 backend role on a team that owns services in production, anywhere in India or fully remote. I'd be joining as someone early in backend work with real depth in a narrow slice of it, and I'd want reviewers who care about correctness enough to tell me when I'm wrong.

I'd rather a system refuse a request honestly than accept it and be wrong about it later.

What testing backends taught me about building them

  1. Make it idempotent before making it fast

    Retries are not an edge case, they're the normal behaviour of every client, proxy and impatient user. An operation that's safe to repeat is a system you can actually operate.

  2. A write and a publish are one transaction, or they're a bug

    Committing to the database and then publishing to a broker is two operations pretending to be one. The outbox pattern exists because that gap is where money goes missing.

  3. Lock the row, not the request

    Optimism about concurrency is fine until inventory is finite. Where correctness beats throughput, take the lock, keep it short, and make the loser of the race fail loudly.

  4. Test where services meet

    Unit tests confirm what you already believe. The bugs live at the boundaries — contract mismatches, timing, partial failure — which is where I spend my testing effort.

03 — Skills

What I build with

Languages

JavaSQL

Backend

Spring BootSpring MVCSpring SecuritySpring Data JPAHibernateREST APIsJWTMicroservicesSpring CloudSpring AI

Messaging & data

KafkaPostgreSQLMySQLRedisTransactional OutboxSaga patternIdempotency

Cloud & DevOps

DockerKubernetesAWSGitHub ActionsMavenGit

Fundamentals

Data Structures & AlgorithmsOOPSystem DesignDesign patterns

Tools

IntelliJ IDEAJira

Hiring an SDE-1 who already knows where backends break?

I'm open to backend roles anywhere in India, and to remote teams. Send a line about what the team owns and I'll reply — including if you want to poke holes in the projects first.

04 — Contact

Every way to reach me