FastAPI in Production: Three Systems and a Hackathon

FastAPI in production works well when the work is a Python API that spends most of its time waiting. We run it in three production systems (an AI study platform, an Instagram analytics product, and an options trading platform) and in a hackathon video analytics build. What held each up wasn't the framework but the decisions around it.

TL;DR: FastAPI is production-ready, but the wins come from habits: short handlers, real queues for slow work, a timeout on every external input, and service lines drawn where failure modes differ. FastAPI's own docs say to use plain def for libraries that can't await. These are the lessons from NoteTube, Pullsy, a trading platform, and Acasa Sentinel.

Each section below covers one system: what FastAPI does there, the failure the design guards against, and the one habit we'd carry to the next build. Where another post goes deeper, we link to it rather than repeat it.

Which systems run FastAPI, and what does it do in each?

Three are in production, one isn't. NoteTube, Pullsy, and a confidential options trading platform run FastAPI for real users. Acasa Sentinel was a hackathon build, and its numbers come from a sandbox. The table shows FastAPI's job in each and the hard part we designed around.

System	Status	What FastAPI does there	The hard part
NoteTube	Production	A separate AI service: retrieval, model calls, streaming chat	Many open streams; keys kept off the clients
Pullsy	Production	The product API and sync engine, with SQLAlchemy and Postgres	Never dropping data from a rate-limited API
Options trading platform	Production, confidential client	Part of the stack around a Rust-core trading engine	Nothing on the API side may slow trading
Acasa Sentinel	Hackathon build, 2026	The API in front of a local video pipeline	Cameras that stall; inference that stays on site

They're very different kinds of software, and that's the point. FastAPI fits when the work is an API and Python is where you need to be: AI libraries, data tools, computer vision, or quant research.

Is FastAPI good for AI backends? The NoteTube answer

Yes, when the AI service is kept separate. NoteTube is an AI learning platform on five surfaces, and all of them talk to one FastAPI service for anything that touches a model. That service holds the provider keys, runs retrieval over the student's own sources in Qdrant, and streams answers back over server-sent events.

A chat request mostly waits: on the vector store, then on a model provider, then on tokens arriving over an open stream. Async handlers let one process hold many of those at once. The failure we designed against was a dead client connection holding server resources, so every stream has an inactivity timeout.

Would do again: put AI behind its own service from day one. It keeps keys in one place, lets the AI side scale alone, and means a slow model call can't block login or billing. The key side of that decision has its own post: how we keep AI API keys out of web and mobile apps.

How does Pullsy keep a sync engine from losing work?

By never running syncs inside a request. Pullsy's FastAPI app serves the web dashboard, a native SwiftUI app, and a public REST API with developer keys. The real work is a sync engine that pulls Instagram data through the official sign-in on a schedule and keeps it after Instagram stops showing it.

FastAPI takes the requests and hands syncs to a Redis queue with an atomic move-with-ack, a delayed-retry set, and per-connection locks, so one account never syncs twice. A scheduler recovers crashed jobs from missed heartbeats. Re-authorization is its own state rather than a failure, because a user who revoked access needs a prompt, not a retry.

The two failures this guards against are a job lost mid-flight and the same account syncing twice in parallel. Why Instagram data disappears in the first place is covered in keeping Instagram insights history, and the retry logic in API rate limit backoff.

Would do again: keep slow, fragile work out of request handlers. A request should finish quickly and hand anything long to a queue that can retry.

The trading platform: FastAPI where it can't hurt

FastAPI sits around the engine, never in it. This is a confidential client: a private platform for index options on an Indian exchange, built on a Rust-core event-driven engine. FastAPI, WebSockets, and server-sent events are part of the stack around that engine, with Redis and a Next.js control dashboard.

The design rule was that nothing outside the engine may slow trading. Market state fans out to the dashboard through Redis and a WebSocket gateway, throttled per instrument. The publisher is bounded and drops when full, so it never blocks the trading path. If the gateway dies, trading doesn't notice.

Market-data decode measured 2.5 µs at p50 in tape replay. That's a replay figure, not a live one, and client, broker, and strategy details are withheld. How the stages are instrumented is in measuring latency in a trading system.

Would do again: design the API layer so it can fail without taking the core down. A bounded queue that drops beats an unbounded one that blocks.

What did a hackathon build teach us about timeouts?

That every external input hangs eventually. Acasa Sentinel was built for the Gujarat Police Hackathon Innovation Challenge 2026. It reads number plates, re-identifies vehicles across cameras, reconstructs routes, and raises watchlist alerts for an operator to confirm. Python and FastAPI sit in front of YOLOv8 with ByteTrack, plate OCR, and DINOv2 embeddings in Postgres with pgvector.

Two decisions shaped the API side. All inference runs locally, so no footage or plate leaves the site. And camera streams have bounded timeouts, so a stalled camera returns in seconds instead of wedging a thread. The same pipeline falls back from CUDA to Apple Silicon to CPU.

Sentinel matched 24 of 24 plates on its proof clip, measured on the running system against the hackathon sandbox, not a production deployment. The pipeline itself is in ANPR on existing CCTV.

Would do again: put a hard timeout on every external input. Cameras, APIs, and file reads all stall sooner or later.

Which FastAPI in production habits would we repeat on every build?

Six habits carried across all four builds. None of them is clever. They're the difference between an API that's calm under load and one that pages you at night, and each one maps to a failure we'd rather not meet twice.

1. Keep handlers short. Validate, do a little work, return. Anything slow goes to a queue or a separate service.
2. Never block the event loop. A blocking driver inside async def stalls every request in that process. FastAPI's docs say to declare a route with plain def when a library doesn't support await, and FastAPI then runs it in an external threadpool (FastAPI docs).
3. Time out everything. Streams, upstream APIs, cameras, model calls. HTTPX, a common FastAPI HTTP client, defaults to a 5-second timeout and lets you set connect, read, write, and pool limits separately (HTTPX docs).
4. Draw service lines where failure modes differ. AI calls, syncs, and trading each fail differently. Separate services keep one failure from spreading.
5. Record what costs money. Tokens, retries, and external calls, per user.
6. Type the edges. Pydantic models on every request and response keep the OpenAPI schema honest, and FastAPI's docs show how to generate client SDKs from it (FastAPI docs).

The async rules in more depth, with examples, are in async FastAPI patterns.

What wouldn't we do again?

Two early instincts didn't hold up. The first was using FastAPI's background tasks for work that must survive a restart. The second was one large app that mixed AI calls, webhooks, and the main API. Both looked simpler on day one and cost more later.

Background tasks are fine for small, fire-and-forget work. FastAPI's docs say as much: for heavy background computation, use a bigger tool like Celery with a queue such as Redis, and keep BackgroundTasks for small jobs like sending an email (FastAPI docs). Anything that must retry belongs in a real queue.

And a single app that mixes model calls, webhooks, and the main API makes every deploy riskier than it needs to be. When one part needs a hotfix, all of it restarts. Ask yourself: if this part falls over, what else should keep running? That answer is where the service line goes.

When we'd pick Django instead

When the product is mostly forms, an admin, and a relational model with permissions. Django gives you more of that out of the box. SigmaCPM, a multi-tenant platform with organizations, seats, and per-module entitlements, runs on Django REST Framework for exactly that reason. The full comparison is on the FastAPI vs Django page.

FAQ

Is FastAPI fast enough for high traffic?

For most products, the database and external calls set the speed, not the framework. FastAPI's async handling helps most when requests spend their time waiting on other systems. If a route is slow, look first for a blocking call, a missing index, or an upstream API without a timeout before blaming the framework.

Where do you deploy FastAPI?

NoteTube runs on Google Cloud Run and Pullsy on Railway, while Sentinel ran on local hardware so footage stayed on site. FastAPI runs anywhere a Python process does, so choose the host for the rest of the system: data location, scaling needs, and what your team already knows how to operate.

Should one FastAPI app serve everything?

Not once failure modes differ. Keep the main API, AI calls, and long-running syncs as separate deployments when one of them can hang or spike. A single app is fine early on, but split it before a slow model call or a webhook storm can take sign-in down with it.

Can you take over an existing FastAPI codebase?

Yes. Start with a review of handlers that block the event loop, external calls without timeouts, and long work running inside requests. Those three cause most trouble in inherited FastAPI code, and fixing them usually matters more than any framework upgrade or rewrite someone may be proposing.

Planning a Python API or an AI backend? See our FastAPI development work, then book a 30-minute architecture call to talk through your system.