Service
AI backend engineering: Python APIs and async workers that hold up in production
I build the backend around AI features — the API, the queue, the database and the failure handling — so a model that works in a notebook keeps working when real users and real traffic hit it.
Who this is for
- Product teams adding an AI feature (an LLM call, a vision model, a classifier) to an existing product.
- Founders whose AI prototype now needs to become a service other systems can depend on.
- Engineering managers hiring a backend engineer who is comfortable around ML code.
Problems I solve
Endpoints are slow because inference, message processing or database writes run on the request thread.
Move the slow work to Celery workers backed by Redis, return immediately, and make each task safe to retry. This is what I did for a client's WhatsApp AI agents at Shivohini TechAI.
The database has to change while the product stays up.
Plan the migration in stages and keep the old path working until the new one is proven. I migrated client databases from MySQL to Supabase/PostgreSQL mid-project while the AI agents kept running.
Pipelines that were fine as a demo fail silently in production.
Add monitoring, recovery and backfill so a crash or network drop doesn't lose data. At Zuneko Labs my work includes hardening internship-era pipelines into monitored, recoverable services.
What you get
- REST APIs in FastAPI (with Pydantic validation) or Django/Flask, with the endpoints documented.
- Background workers with Celery + Redis: queues, retries and idempotent tasks.
- PostgreSQL schema design and migrations with SQLAlchemy; MongoDB where the data is event-shaped.
- Integration of model inference or LLM APIs behind a stable interface.
- Webhook ingestion and third-party integrations (WhatsApp Business API, Twilio, Google Drive).
- Docker images, a GitHub Actions pipeline and tests with pytest.
Technology, and where it fits
- FastAPI + Pydantic
- Default for new async APIs and model-serving endpoints.
- Django / Flask
- Used where the project already runs on them, e.g. the CCTV analytics backend.
- Celery + Redis
- Async workers for inference, message processing and database writes.
- PostgreSQL / Supabase, SQLAlchemy
- Relational data and migrations, including a live MySQL → PostgreSQL move.
- MongoDB
- Event storage with a flexible shape — detections, bounding boxes, timestamps.
- Docker, Nginx, GitHub Actions
- Packaging, serving and CI for the services above.
Evidence
- CCTV analytics case study
Django backend with a Celery worker pool processing video frames off the main thread.
- Speech emotion recognition case study
Deep-learning model behind a real-time inference pipeline with a Django REST backend.
- Agentic Honey-Pot (GUVI AI Impact Buildathon 2026)
FastAPI orchestration backend with API-key auth and rate limiting. Source on GitHub.
Trade-offs worth knowing
A task queue isn't free
Celery + Redis means a broker and workers to deploy and watch. For low volume, a FastAPI background task or a scheduled job is often enough, and I'll say so.
FastAPI or Django
FastAPI suits async, API-only services and model endpoints. Django is better when you need its admin, ORM and auth out of the box. I don't rewrite a working Django app just to switch.
PostgreSQL or MongoDB
Relational data with integrity rules goes in PostgreSQL. High-volume events whose shape changes — like detection logs — can fit MongoDB better.
Limitations
- I'm a backend engineer first. I've used React on projects, but I don't take frontend-only work.
- My Kubernetes and AWS/GCP experience is at the fundamentals level; for heavy cloud infrastructure you'd want a dedicated DevOps engineer alongside me.
Frequently asked questions
Do you work with international clients?
Yes. I'm based in Pune, India, and work with teams in India and remotely worldwide. Communication is async-first with scheduled calls when needed.
FastAPI or Django — which should I choose?
FastAPI suits async, API-only services and model-serving endpoints. Django is better when you need its admin, ORM and auth out of the box. I don't rewrite a working Django app just to switch frameworks.
Do I need Celery and Redis, or is that overkill?
For a few jobs a minute, FastAPI's BackgroundTasks or a scheduled job is often enough — and I'll say so. The queue earns its keep when work is slow, spiky, or must survive worker restarts.
How does an engagement work?
A short scoping call, a written scope (what gets built, what doesn't, how we'll know it works), then small reviewable milestones — with the code in your repository and a handover walkthrough at the end.
How we'd work together
- A short call to understand the problem, your current system and your constraints.
- A written scope: what will be built, what won't, and how we'll know it works.
- Build in small milestones you can review, with the code in your repository.
- Handover: documentation, deployment notes and a walkthrough.
Open to full-time roles as well as freelance and consulting work.
Discuss a project
Tell me what you're building and where it's getting stuck. Freelance, consulting and full-time conversations are all welcome.