Senior Software Engineer — India

I build backend systems
that stay correct
under pressure.

Nine years across retail, supply chain, payments, investment banking and healthcare — event-driven Java services, Kafka pipelines and AWS platforms. I also architected and shipped a multi-tenant SaaS product solo, now live on Google Play.

See the workGet in touch
9+ yrs
Backend engineering across six business domains
60%
Lower event volume and processing cost via stateful deduplication
150%
Faster API execution on a production payments platform
<150ms
End-to-end latency held at high-velocity fulfillment hubs
01 — Selected work

Four systems, four different hard problems.

Client engagements are described without internal system names. The platform I own is documented in full.

● Live on Google PlayFlutterFirebaseNext.js 15TypeScriptGCP

FitTrack & Fittie — multi-tenant gym management SaaS

Independent product · Solo architect & engineer · 2025–present
  • Three surfaces, one contract. A gym-owner app and a member app on Google Play, plus a Next.js platform dashboard — all sharing one documented Firestore data contract and 11 Cloud Functions.
  • The browser never touches the database. Every platform read goes through a callable that checks a super-admin custom claim. No public registration, no claim-bootstrap route, PII masked in list responses, and audit logs recursively redacted for tokens and credentials.
  • Reconciliation warnings, never silent zeros. Missing amount mappings surface as explicit warnings rather than defaulting to zero, and every response carries a dataAsOf timestamp.
  • Production deploys with no stored credentials. GitHub OIDC, approval-gated releases, authenticated and unauthenticated canaries, and automatic rollback to a last-known-good commit on partial failure.
Interactive — the idempotency trap I hit, and the fix
Idempotency receipts never expire. That is correct for retries and catastrophic for reuse. Tap “Check in” twice and watch what the receipt does.
operationIdcheckin:gym_42:user_7
Server-side writes
visitOperations receipt—
attendance—
memberPresence—
gym occupancy—
Awaiting first check-in…
RedisSpring Data RedisAWS ElastiCacheTerraformCloudWatch

Finding a framework-level memory leak two previous attempts had missed

Large US omnichannel retailer · via consultancy · 2025–2026
  • A production ElastiCache for Redis cluster was hitting 100% memory daily, paging to disk on reader nodes and collapsing to a 0% hit rate, which dumped the load straight onto the primary database. Two earlier efforts had not found the cause.
  • The diagnosis was a chain of four commands. Non-blocking SCAN from a bastion host surfaced container keys with a TTL of -1; TYPE showed they were Sets; SCARD showed millions of members; and EXISTS on a random member returned 0. The entities had expired. Their IDs had not.
  • The framework only cleans those indexes if it hears about the expiry. Spring Data Redis removes an ID from its secondary index when its key-expiration listener fires, and that listener depends on Redis keyspace notifications. Managed Redis leaves those off. So @RedisHash entities expired silently and their IDs stayed behind — millions of orphaned references, an unbounded leak that no application code owned.
  • The fix had to not be the outage. Deleting members with SMEMBERS or KEYS is O(N) on a single-threaded server, so cleanup ran as cursor-based SSCAN in 500-key batches with pipelined existence checks and pipelined SREM. Keyspaces are discovered by scanning the Spring context for @RedisHash repositories rather than hardcoded, so a new cache is covered the day it ships.
  • Purging millions of keys then fragments the heap. Reclaiming the memory needed activedefrag and a tuned maxmemory-policy applied through a Terraform-managed ElastiCache parameter group — no cluster restart.
  • Three tiers, because one is a single point of failure. A nightly preventative job, a CloudWatch and SNS alarm at 80% memory, and an authenticated admin endpoint so an on-call engineer can force a cleanup mid-incident.
Metric
Before
After
Peak memory usage
100% — OOM crash loop
~22–25% stable
Swap paging on reader nodes
>22 MB
0 MB
Memory fragmentation ratio
>2.2 and spiking
1.05 – 1.15
Cache hit rate
0 – 30%, volatile
>85%, stable
Unscheduled downtime
Daily OOM restarts
None
JavaSpring BootKafkaRedisKubernetes

Rebuilding an inventory pipeline so business rules ship without deploys

Large US omnichannel retailer · via consultancy · 2025–2026
  • Migrated an enterprise inventory pipeline from hardcoded processors to a configuration-driven decorator architecture, so rule changes across diverse fulfillment nodes no longer required a deployment.
  • Built a deterministic transition-rule engine that split physical warehouse movements into logical financial transactions for reverse logistics and brand transformations.
  • Cut downstream event volume and processing cost by up to 60% with Redis-backed stateful deduplication that filtered logical no-op updates.
  • Protected raw audit trails with immutable state boundaries and deep copies, and quarantined unmapped inventory through fail-fast validation and dead-letter routing — holding sub-150 ms end-to-end latency.
Java 19Spring Boot 3AWS LambdaKafkaOracle

Moving a payments platform off-premise without losing correctness

Global payments provider · via consultancy · 2021–2024
  • Modernised on-premise legacy applications into AWS services and delivered new remittance operations, improving API execution speed by 150%.
  • Built a Kafka-listener billing service that captured events, generated billing files and delivered them to S3.
  • Created Cucumber regression automation to protect existing behaviour during continuous deployment, and migrated the database from PostgreSQL to Oracle for the beta release.
  • Mentored a junior engineer and coordinated technical requirements directly with stakeholders.
02 — Capabilities

What I reach for.

Backend

Java 8/11/19, Spring Boot, Spring MVC, Hibernate, REST APIs, microservices

Architecture & reliability

Distributed systems, event-driven architecture, multi-tenant security models, idempotency & deduplication, schema evolution, DLQ and fail-fast validation, low-latency tuning

Event streaming & data

Kafka, Avro, Schema Registry, Redis, Apache NiFi, Oracle, PostgreSQL, MySQL, MongoDB, Cassandra, Firestore

Quality & AI-assisted delivery

Cucumber BDD, JMeter, Vitest, emulator-based integration testing, Claude Code for reusable engineering automation

Cloud & DevOps

AWS Lambda, API Gateway, EventBridge, S3, DynamoDB, CloudFormation · GCP Cloud Run, Cloud Functions, IAM · Docker, Kubernetes, Jenkins, GitHub Actions

Frontend & mobile

Flutter, Dart, React, Next.js, TypeScript, JavaScript ES6

03 — Experience

Nine years, six domains.

2025 — 2026

Senior Software Engineer (Contract)

Spectraforce Technologies · Retail & supply chain
Java · Spring Boot · Kafka · Redis · Avro · Kubernetes
2024 — 2025

Senior Software Engineer

Apexon · Investment banking · Birmingham, UK
Java 19 · Apache NiFi · Kafka · Kubernetes
2021 — 2024

Senior Software Engineer

UST Global · Payments · Leeds, UK
Java 19 · Spring Boot 3 · AWS · Kafka · Oracle · React
2020 — 2021

Senior Software Engineer

Sri Mookambika InfoSolutions · Healthcare · Chennai
Java 11 · React · AWS Lambda · CloudFormation
2016 — 2020

Full Stack Developer

IVTL Infoview Technologies · Supply chain & expense management · Chennai
Java 8 · Spring MVC · Hibernate · MySQL · Cassandra
04 — Engineering writing

I document decisions, not just code.

Systems outlive the people who build them. These are the artefacts I produce alongside the software.

Handover

A 7-section engineering handover for two programs

Architecture, data contracts, risk register, unresolved unknowns marked explicitly, and a first-week plan for whoever inherits it. Available on request.

Contracts

Firestore data contract & security matrix

Collection-by-collection ownership, which writes the backend owns, and what each actor can read. The rules are the authorisation boundary, so they are documented as such.

Decisions

Deliberate mismatches, recorded

A published package name can never change, so a brand rename lives only in labels and listings. Written down as intent so nobody “fixes” it later.

05 — Contact

Open to senior backend
and platform roles.

Based in Tamil Nadu, India. Available immediately, comfortable across UK, EU and US time zones, and set up to work with global teams remotely.

EmailLinkedInGitHubDownload resume (PDF)