Senior Software Development Engineer · Gurgaon
Ten years of platforms with real users on the other end.
Amazon, 2016 to 2026, after an internship there in 2015. Bengaluru first — seller tools for the India marketplace — then Seattle, building internal career-mobility products that ran in fourteen countries. Finished at the senior level, SDE III.
- SDE III · 2024–26
- SDE II · 2018–24
- SDE I · 2016–18
- B.Tech CSE, IIT Kanpur · 2016
Numbers that hold up
- 250ms → 40ms API latency
- After a database migration and schema redesign.
- 20 → 5 tables
- The same redesign, built around key-based access.
- 66% TPS reduction
- Downstream load, after an API redesign.
- 32 → 2 min UI test time
- A 94% cut, across eight languages.
- ~800ms latency removed
- Taken off a busy page’s render path.
- 99%+ line coverage
- A notification platform, with 100% branch coverage.
- 12 countries launched
- Europe and Australia, in four phased launches, on schedule.
- 10 days → 12 hrs incident detection
- For email failures that had been going unseen.
Four systems
The work I would most want to be asked about, drawn rather than described — the shape is the argument.
2018–2019
One service where there had been ten scripts
Notifications were scattered across years of ad-hoc jobs. Ten-plus script-based senders each tracked their own success, errors and retries, so nobody could answer the only question that mattered: did it arrive? I proposed the consolidation, got approval, and built one platform across WhatsApp, SMS and email — opt-in and preferences, event dispatch, per-market configuration and channel metrics, with each market enabled behind an experiment.
Unified notification platform. Two ingress paths, one service, three channels.
What was hard The return path. Provider status callbacks reconcile through a serverless function into a key-value store under composite keys, so delivery state is a single lookup instead of living in ten scripts’ private logs.
2022–2026
A GraphQL platform, built from nothing
A gateway and its data layer, built from nothing on a managed GraphQL API, serverless functions and a key-value store, all as infrastructure as code. I wrote the low-level design — service decomposition, data flow, per-resolver caching, when to chain resolvers and when not to — and the schema-driven patterns the team adopted. It grew into five microservices across several languages.
GraphQL platform. Schema-driven gateway, single-table store, event fan-out.
What was hard Choosing GraphQL over REST for clients whose query shapes kept changing, then keeping a single-table design honest as access patterns multiplied. Changes fan out from the table’s change stream through pub/sub, so consumers never poll.
2025
Configuration that stops drifting
Two independently-owned services held overlapping configuration and drifted apart by hand. I designed an event-driven sync: a config object lands in object storage and flows through a pub/sub topic, a FIFO queue, schema validation and an approval gate before it is written. The schema underneath is hierarchical, with per-attribute overrides, so a product manager can change behaviour without a deployment.
Cross-service configuration sync. Ordered, validated, gated, idempotent.
What was hard Ordering and replay. FIFO delivery keeps changes in sequence and the final write is idempotent, so a redelivery cannot corrupt the target. The gate keeps a human in the loop without putting one in the critical path.
2024–2025
Finding failures that were failing silently
Email delivery failures were going unnoticed for over a week. I integrated a preference service to stop the bleeding, then built the monitoring so the next one would surface in hours rather than days.
Bounce monitoring. Per-template metrics turn an invisible failure into a paging one.
What was hard Granularity. Aggregate bounce rates hid the problem — one misbehaving template disappears into a healthy overall number. Per-template metrics, composite alarms and a daily report cut detection from ten days to under twelve hours.
Ten years, four rooms
- 2024–2026Seattle · career mobility
Senior Software Development Engineer (SDE III)
Career-mobility features across fourteen countries and forty-odd locales.
- Led a twelve-country expansion across Europe and Australia in four phased launches, coordinating dependency teams in several organisations, then wrote the eight-step runbook that cut each later country launch by roughly 60%.
- Drove requirements for runtime country-level feature flags, turning a multi-day deployment cycle into a rollout or emergency rollback measured in minutes.
- Took a core service to full continuous-delivery certification in a week against a three-week estimate, then made the work reusable, cutting the remaining pipeline work by about a third.
- Replaced brittle matching with a typed API; caching cut downstream load by 66% and removed multi-second latency spikes, and it fixed a defect where English-only patterns failed against localised job titles.
- Designed self-service onboarding for new roles, with fail-closed validation and automatic tickets for missing translations, breaking a dependency bottleneck.
- Ran a production data backfill through six optimisation phases — a tenfold improvement — with no failures and no race conditions.
- Deprecated legacy infrastructure in three phases with no downtime.
- 2021–2024Seattle · across several teams
Software Development Engineer II
Internal mobility products, and a stretch on seller logistics.
- Tech lead for a new employee-facing platform — later live in fourteen countries — owning its architecture end to end from inception, including the move off the legacy third-party tool it replaced.
- Built a configurable matching engine so product managers could tune how candidates rank against roles without a code change.
- Delivered time-boxed delegation, so managers could hand over talent-review access that expired on its own.
- Designed the metrics pipeline behind internal-transfer analytics.
- Led a micro-frontend migration for two product surfaces onto a shared rendering framework.
- Earlier in the stretch: a capacity-reservation system for a logistics platform, taken through operational readiness into production, and auto-resolution for seller claims across multi-country launches — partial cancellations, multi-shipment orders, the awkward cases.
- 2018–2021Bengaluru · seller experience
Software Development Engineer II
Global marketplace tools, tax compliance, and international expansion.
- Proposed, designed and built a unified multi-channel notification platform, then its WhatsApp channel end to end.
- Built the action handler behind those notifications, with an integration-test harness and a load-test pipeline.
- Delivered a tax-compliance change for marketplace sellers inside the government deadline.
- Built validation and opt-in for a seller promotions feature, later extended to mobile.
- Authored the technical design for taking a seller claims programme into Saudi Arabia and Egypt, with a right-to-left Arabic interface, and led QA and accounting validation for those launches.
- Selected to train as a code-review Bar Raiser — a reviewer trusted to hold the quality bar on other people’s changes — the first junior engineer on the team to be picked, with 225+ reviews.
- 2016–2018Bengaluru · registration & onboarding
Software Development Engineer I
Seller onboarding, rewards, and India’s GST transition.
- Built a post-launch page for new sellers from scratch, and was first on the team to roll a change out gradually behind an experiment. It shipped with zero high-severity tickets.
- Built the analytics pipeline behind it, consolidating many files a day into one daily load.
- Worked on India’s GST transition across several seller-facing services, delivered three days ahead of the government deadline.
- Wrote the staging, validation and backfill tooling for that transition.
- Led a rewards service’s database migration and schema redesign; average API latency fell from 250ms to 40ms, and partial updates halved QA effort.
- Built the subscription model and an operations admin panel so non-technical teams could manage reward programmes without code changes.
- Mentored a six-month intern end to end, and gave the team’s first recorded tech talk, on serverless functions.
Before Amazon
IIT Kanpur — B.Tech, Computer Science and Engineering, 2012–2016.
- Summer 2015 at Amazon in Bengaluru, interning on a seller-facing team: a tool that turned raw product data into a validated catalogue feed. Full-time from July 2016.
- Co-founded jutja.com, a project-management site that laid tasks out as mind maps, and built its front end.
- Projects across computer vision, distributed systems, compilers and graphics — licence-plate detection on the campus surveillance feed, skyline queries on MapReduce, a Java-to-MIPS compiler, 3-D Tetris in OpenGL.
Design documents
Some of the work never becomes a service — it becomes the argument that settles which service gets built.
- A reporting service, re-architected
- An API that pulled entire datasets into the service and filtered them in code — memory pinned at 100%, and the largest exports timing out at the gateway. The proof of concept moved long exports to an asynchronous job that says when the file is ready, built on federated queries.
- A failure-notification pipeline
- Event-driven, with parallel eligibility checks, dead-letter fault tolerance and expiring-link resource delivery. Preceded by a feasibility study on event-source reliability and multi-channel delivery timing.
- Migrating an in-app notification surface
- Compared three architectures — in-service rendering, event-driven push, and a hybrid pull/push — with lifecycle management, alarm root-cause analysis and a cost-versus-latency trade-off for each, sized four ways.
- Choosing a data store on evidence
- A cached key-value store against a managed configuration service with client-side extensions and auto-rollback on alarms. Cost, latency and failure modes compared so the team could pick on evidence.
- A data-lineage investigation
- Traced one field across five services, showing how a single upstream decision to stop providing it propagated silent failures into three downstream APIs, each carrying its own duplicate workaround.
- Per-client throttling at the edge
- Consolidating six API domains onto one endpoint concentrates blast radius, so throttling went in per consumer with tiered limits and a catch-all block.
- Identity-native per-caller throttling
- Argued that the caller’s resolved identity is already in the service logs, so enforcement needs no onboarding from callers — a distributed token bucket with shadow, enforce and fail-open rollout modes.
- Indexing live records by expiry, not status
- Moving a service off a relational database, the obvious index — status — would have returned every expired record and left the filtering to code. Indexing on expiry date returned only live records, with status filtered from a list the caller passes. Multi-table joins became key lookups.
- Subscribing to delivery updates instead of polling for them
- Delivery status lived in another team’s service. Polling meant re-checking every message ever sent and loading their service to do it; subscribing to its update events delivered each change once. Update types we didn’t recognise were kept, not dropped.
- One read instead of seven calls
- A generic interceptor ran before a busy page rendered, and its first design asked seven services — about 800ms, and seven ways to fail. Each user’s status went into one read-optimised store keyed by user: one lookup, one dependency.
- Seven blocks, one template, a flow that remembers
- A page’s seven independent blocks became fragments on one abstract template, so a new block is configuration. The step completes itself on load so it shows exactly once, users stay pinned to the flow they started in, and the rollout went behind an experiment.
Also shipped
- A Go-to-Java runtime migration — the executive plan and the infrastructure hardening: 49 integration tests, 26 load tests, and custom DNS consolidating six domains onto one endpoint.
- An ML deployment pipeline design that removed manual infrastructure edits between model registration and production.
- AI-assisted internationalisation validation — CLI tooling detecting cross-locale spelling, URL formatting and translation inconsistencies across 40+ languages.
- Text-to-speech greetings in an onboarding flow, generating personalised audio for new users.
- Static-analysis onboarding across eight service packages, with baselines and quality gates.
Running things in production
- Two production incident reviews, authored
- A multi-hour failure during a live launch — root cause in 77 minutes, resolved in nine hours. And an outage traced to header handling in a reverse proxy, mitigated in 66 minutes behind a feature gate, with a five-whys root-cause analysis and thirteen action items behind it.
- An outage that kept a calendar
- Database connection-pool timeouts every couple of months, clearing on their own within hours, with no root cause. Added performance insights, enhanced monitoring and error-log shipping, right-sized the instances and added reader auto-scaling — then lined the outages up against the database credential’s 60-day automatic rotation. The service’s copy of the secret was falling out of sync each time.
- An alarm audit that found the alarms were not connected
- Most of the composite alarms across a set of production services routed to nobody. Fixed those, then added real-user monitoring for Web Vitals and automated investigation on alarm-triggered tickets.
- Tech debt, counted rather than argued about
- Audited pipeline health and continuous-delivery maturity across the platform and used blocking-chain reasoning to show one migration unblocking three initiatives at once. That turned a standing argument into a prioritisation decision.
- Operational readiness as a standing cadence
- Owned five readiness reviews and served as change-management point of contact for the platform — a change template, a monthly deployment SOP, escalation criteria for high-severity incidents with quantified thresholds, and on-call procedures covering every launched country.
- Planning that checks itself against production
- Annual roadmap sizing where each incoming request was checked against the code already shipped — which found one request already complete and another needing no engineering from the team at all, and routed it to its real owner.
Stack
- Languages
- Java
- Python
- JavaScript / Node.js
- TypeScript
- Go
- Kotlin
- GraphQL
- SQL
- AWS
- Lambda
- DynamoDB
- DAX
- AppSync
- SQS
- SNS
- S3
- CloudWatch
- EventBridge
- Step Functions
- AppConfig
- API Gateway
- CloudFront
- WAF
- Route 53
- KMS
- IAM
- Patterns
- Event-driven
- Single-table design
- Schema-driven GraphQL
- Serverless-first
- FIFO + idempotent writes
- Feature flagging
- Infrastructure as code
- Tools
- AWS CDK
- Netflix DGS
- Dagger 2
- Guava
- Spring Boot
- React Native
Working with people
- Around 300 code reviews a year, with feedback on race conditions, internationalisation regressions, monitoring gaps and security risk rather than formatting.
- Ran a promotion assessment across nine stakeholders including three principal engineers, and wrote evidence-based promotion feedback for several teammates.
- Interviewed for SDE and campus hiring across multiple quarters — coding, system design and behavioural.
- Gave internal tech talks — on serverless functions, on running a whole GraphQL API from a single function, and on federated queries over a relational store.
- Mentored engineers through migrations, schema design and service onboarding without taking the work off them.
- Built the team wiki from scratch — services, runbooks, dev setup, architecture, dashboards — replacing tribal knowledge with something a new joiner could read.
- Drove AI-assisted development across engineering, product and data teams, including the guardrails that stop it doing damage.
What I am looking for
Senior engineering roles in Bengaluru — distributed systems, platform work, or anything where owning the whole lifecycle is the point. Open to conversations now.