Backend Developer · WAT (UTC+1)
Backend engineer focused on building reliable APIs, async systems, and data pipelines in Python. I care about clean architecture, honest error handling, and systems that work under real load — not just in demos.
A Flask REST API that classifies names by predicted gender, age, and nationality using external APIs. Features GitHub OAuth with PKCE, Redis-backed caching and rate limiting, natural language search, CSV bulk ingestion via Polars streaming, and a dashboard with aggregate statistics.
Python, Flask, SQLAlchemy, PostgreSQL, Redis, Polars, GitHub Actions, Vercel
An HTTP retry service that queues failed outbound API requests and retries them with exponential backoff and jitter. Built for scenarios where backends call external services that occasionally fail — payment gateways, SMS providers, banks.
Python, FastAPI, SQLite (WAL mode), httpx, Pydantic, asyncio
A collaborative platform where event organisers create and share customizable digital badges for hackathons, conferences, and meetups. Full async stack with PostgreSQL, Redis-backed job queues, and Cloudinary media storage.
Python, FastAPI, SQLAlchemy 2.0, PostgreSQL, Redis, arq, Cloudinary, Alembic
All three projects — REST endpoints with versioning, pagination, filtering
Insighta Labs+ (GitHub OAuth + PKCE, JWT with refresh rotation), Social Badge (JWT + bcrypt)
Insighta Labs+ (PostgreSQL, 6 custom indexes), Retry Engine (SQLite WAL), Social Badge (PostgreSQL + Alembic migrations)
Insighta Labs+ (Redis response cache with SHA-256 keys, cached COUNT queries), Social Badge (Redis)
Retry Engine (async polling worker), Social Badge (arq Redis-backed job queue)
Social Badge (pytest + pytest-asyncio + fakeredis), Retry Engine (integration test suite with mock server)
Insighta Labs+ (Vercel serverless), all projects (GitHub Actions CI)
Insighta Labs+ (Flask-Limiter + Redis, per-identity limits), Social Badge (slowapi)
Insighta Labs+ (streaming CSV upload — 500k rows via Polars, 50k-row batch INSERTs with per-batch rollback)
When a backend calls external services — payment gateways, SMS providers, bank APIs — those calls sometimes fail due to transient network issues or rate limits. Without a retry mechanism, those failures are silently lost. I needed a self-contained service that could queue failed requests, retry them intelligently, and provide full visibility into what happened.
Client submits a request via POST /request. FastAPI stores it in SQLite and returns immediately with a pending status. A background async worker polls every 500ms for due retries, executes the HTTP call via httpx, and transitions the request through a state machine: pending → retrying → completed or failed. SQLite runs in WAL mode for safe concurrent reads and writes. No external message broker — the worker is an in-process asyncio task, keeping the system zero-dependency.
POST /requestSubmit a request for retry. Returns {id, status: pending} immediately.GET /requests/{id}Fetch a single request with full attempt history.GET /requests?status=List requests filtered by status (pending, retrying, completed, failed).The main challenge was preventing thundering herd — when many failed requests share the same backoff schedule, they all retry at the same instant and overwhelm the target service again. I solved this with jitter: each retry delay is multiplied by a random factor between 0.8 and 1.2, spreading retries across a window instead of a single point. Combined with the exponential backoff formula (baseDelay × 2^attempt), this keeps retry pressure smooth even under burst failures. I also made 4xx responses fail immediately — client errors won't self-correct on retry, so burning through attempts on a 400 is wasteful.
Before HNG, I understood how to build APIs. During HNG, I learned how to build APIs that hold up. The Insighta Labs+ project forced me to think about caching not as an optimization but as a requirement — without Redis response caching and query normalization, the same search hit the database dozens of times per minute. I learned to bypass the ORM for list endpoints because hydrating 50 objects per page was measurably slower than raw mappings.
The retry engine taught me async discipline — managing background tasks that outlive individual requests, handling graceful shutdown, and writing state machines where every transition is explicit. Working on Social Badge as part of a team was a different kind of challenge: reading other people's code, writing tests against existing schemas, and shipping features that don't break what's already there.
The biggest shift was in how I think about failure. I used to write code for the happy path and handle errors as an afterthought. Now I design for the failure case first — what happens when Redis is down, when a CSV has 500k malformed rows, when a token gets replayed. That's the change I'm keeping.