Akshit Khandelwal

Backend Engineer · Java · Spring Boot · PostgreSQL · Distributed Systems

I build multi-tenant backend systems. What interests me most is the part that decides what happens when something fails: retries that don't duplicate, races that don't lose writes, failure states you can query instead of guess at. Currently at Volkswagen Group Digital Solutions, where I took a vulnerability-management platform from proof of concept to production for three enterprise clients.

Selected work

Escalade — self-hostable on-call escalation engine

The service that decides who gets paged, on which channel, after how long, and what happens when nobody acknowledges. Built to demonstrate the delivery guarantees that make an alerting system trustworthy, rather than a CRUD wrapper over a notifications table.

An incident is triggered twice, the second is deduplicated, escalation walks two policy steps on its own, and an acknowledgement cancels the step that had not yet paged. — A monitoring alert fires twice (the second is deduplicated), escalation walks the policy on its own, and acknowledging cancels the step that had not yet paged.

Guarantee	Mechanism
A retried webhook never pages twice for one outage	Idempotent create via a partial unique index `UNIQUE (org_id, dedup_key) WHERE status='OPEN'`. Enforced in the database, not by a racy `SELECT`-then-`INSERT`.
Multiple workers, no double-sends, no message broker	`SELECT … FOR UPDATE SKIP LOCKED` job claiming. Each worker locks a disjoint batch and skips rows another holds.
An ack landing exactly as the next step fires can't be lost	Optimistic locking (`@Version`). The losing transaction rolls back and retries, so an acknowledged incident never pages again.
A failing channel surfaces instead of silently swallowing a page	Capped retries with exponential backoff into a queryable `dead_letter` row. A dead channel does not halt the ladder, because a Slack outage must not stop someone being paged by email.
"Nobody responded" is a state, not silence	When escalation runs out of steps the incident is swept to `DEAD_LETTERED` after a grace period; late acknowledgements still work.

Spring Boot 3 · Java 21 · Spring Data JPA · PostgreSQL · Flyway · Testcontainers · Micrometer/Prometheus · Docker Compose · GitHub Actions

Source Design notes

Experience

Software Engineer — Volkswagen Group Digital Solutions

Aug 2023 – present

Took a multi-tenant vulnerability-management platform from proof of concept to production, serving 3 enterprise clients and 120+ monitored servers.
Designed the multi-tenant data model and the reusable services around it: Cloud IDP authentication, large file upload, and notification delivery.
Built O365 email integration with threaded reminders and escalation, cutting unresolved vulnerable servers from 30 to 5 out of 120.
Integrated LDAP certificate retrieval and PKI email encryption to work around O365's limits on certificate-based encrypted mail.
Sole developer on the platform: architecture, code review, and deployment across AWS and on-premise environments.

Data Engineer Intern — DataWeave

Jan – Jun 2023

Built distributed web-scraping pipelines in Python and Selenium against dynamic sites and mobile apps.
Moved scraping orchestration onto distributed task scheduling, cutting project delivery timelines by 20%.
Automated data validation and quality checks feeding SQL and S3 storage.

Writing

Why I claim jobs with SKIP LOCKED instead of a message broker
Postgres as a work queue, what it actually guarantees, and the point at which this stops being the right answer.
The ack-versus-escalate race, and the lock that closes it
An acknowledgement arriving in the same millisecond as the next escalation step, and why optimistic locking beat the alternatives.
At-least-once delivery without paging anyone twice
Retries make duplicates inevitable. Where to put the idempotency boundary so they never reach a human.

Education

B.Tech, Computer Science — NIIT University

2019 – 2023

Alwar, Rajasthan · 8.71/10