DEV Community: Madhav Bhasin

What the FastAPI Docs Don't Tell You About Production

Madhav Bhasin — Tue, 21 Jul 2026 11:56:15 +0000

The service had been live for weeks. Locally, staging, early production — fast, clean, no issues. Then a new client onboarded, traffic doubled overnight, and P99 latency climbed from under 100ms to over 4 seconds.

No 5xx spike. No memory pressure. No CPU ceiling. Just slow.

Two things were wrong. Both came directly from patterns copied out of the FastAPI docs.

Problem 1: A New DB Connection on Every Request

The FastAPI quickstart doesn't show you how to manage shared resources. So most services end up doing this:

# ❌ What most people write first
@app.get("/orders/{order_id}")
async def get_order(order_id: str):
    conn = await asyncpg.connect(DATABASE_URL)  # new connection every request
    order = await conn.fetchrow("SELECT * FROM orders WHERE id = $1", order_id)
    await conn.close()
    return order

Fine locally. Under 50 concurrent requests on Cloud Run hitting Cloud SQL, this means 50 simultaneous TCP handshakes + authentication attempts. PostgreSQL has a finite connection limit. Requests queue waiting for a slot. Latency compounds.

The fix is a connection pool initialised once at startup via FastAPI's lifespan hook — not per-request, not as a module-level global:

# ✅ The right way
from contextlib import asynccontextmanager
from fastapi import FastAPI
import asyncpg

@asynccontextmanager
async def lifespan(app: FastAPI):
    app.state.db = await asyncpg.create_pool(DATABASE_URL, min_size=2, max_size=10)
    yield
    await app.state.db.close()

app = FastAPI(lifespan=lifespan)

@app.get("/orders/{order_id}")
async def get_order(order_id: str, request: Request):
    async with request.app.state.db.acquire() as conn:
        return await conn.fetchrow("SELECT * FROM orders WHERE id = $1", order_id)

Same pattern applies to Redis clients, HTTP sessions, and any SDK that's expensive to initialise. If it's shared, it belongs in lifespan.

Problem 2: Stack Traces Leaking to Clients

While diagnosing the latency issue, we found something else in Cloud Logging. Clients were receiving this:

{
  "detail": "500: Internal Server Error\nTraceback (most recent call last):\n  File \"/app/routers/orders.py\", line 34...\nasyncpg.exceptions.TooManyConnectionsError: ..."
}

Internal file paths. Dependency names. Exception types. Leaking silently for weeks.

FastAPI's default behaviour on an unhandled exception exposes more than you want in production. The fix is a single catch-all exception handler:

# ✅ Global exception handler
import logging
from fastapi import Request
from fastapi.responses import JSONResponse

logger = logging.getLogger(__name__)

@app.exception_handler(Exception)
async def unhandled_exception_handler(request: Request, exc: Exception):
    logger.exception(
        "Unhandled exception",
        extra={"path": request.url.path, "method": request.method}
    )
    return JSONResponse(
        status_code=500,
        content={"error": "internal_server_error", "message": "Something went wrong."}
    )

Full traceback goes to Cloud Logging — where only your team sees it. Clients get a safe, consistent error shape. One file, set it once, never think about it again.

Three More Things the Docs Skip

1. Structured logging

Default uvicorn logs are human-readable text. Cloud Logging expects JSON. Replace the default logger before your first deploy:

import logging, json, sys

class JSONFormatter(logging.Formatter):
    def format(self, record):
        return json.dumps({
            "severity": record.levelname,
            "message": record.getMessage(),
            "logger": record.name,
        })

handler = logging.StreamHandler(sys.stdout)
handler.setFormatter(JSONFormatter())
logging.root.handlers = [handler]
logging.root.setLevel(logging.INFO)

2. Uvicorn config for Cloud Run

Don't copy --reload from the quickstart into your Dockerfile. For Cloud Run:

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080", "--workers", "1", "--loop", "uvloop", "--timeout-keep-alive", "30"]

Single worker per instance (Cloud Run scales horizontally, not vertically), uvloop for async performance, no --reload.

3. A health check that actually checks something

@app.get("/health")
async def health(request: Request):
    try:
        async with request.app.state.db.acquire() as conn:
            await conn.fetchval("SELECT 1")
        return {"status": "ok"}
    except Exception:
        return JSONResponse(status_code=503, content={"status": "degraded"})

A health endpoint that just returns {"status": "ok"} is a lie. Cloud Run routes traffic based on this endpoint — a lying health check sends requests to a broken instance.

The framework didn't fail. The configuration did.

Next: S01E02 — FastAPI + Pydantic in Production: Contracts, Validation, and Versioning.

AWS S3 as an Image Hosting Service

Madhav Bhasin — Sat, 01 Apr 2023 03:51:33 +0000

In today's digital world, images are an essential part of online communication. From personal blogs to e-commerce websites, images are used to convey messages, showcase products, and enhance the overall user experience. However, hosting and managing images can be a daunting task, especially for websites with a large number of visitors. This is where Amazon S3 comes into play as an excellent image hosting service.

Amazon S3, or Simple Storage Service, is a cloud-based object storage service that allows users to store and retrieve any amount of data from anywhere on the internet. With its high scalability, durability, and security, S3 has become the go-to solution for image hosting, serving as a reliable and cost-effective alternative to traditional hosting services.

Here are some of the benefits of using AWS S3 as an image hosting service:

Cost-effective: S3 pricing is based on usage, making it a cost-effective solution for image hosting. With S3's pay-as-you-go pricing model, you only pay for the storage and bandwidth you use, with no upfront fees or long-term commitments. This makes S3 an ideal option for websites with varying traffic patterns or those looking to reduce their hosting costs.
High Scalability: S3 allows you to store an unlimited number of images and scales effortlessly to handle any increase in traffic. As your website grows and attracts more visitors, S3 can handle the increased traffic without any downtime or interruptions, making it a scalable solution for image hosting.
Durability: S3 is designed to ensure 99.999999999% durability and 99.99% availability of objects over a given year. This means that your images will always be available to your users, regardless of any hardware failures or network issues.
Security: S3 offers multiple security features to protect your images from unauthorized access, including access control lists, bucket policies, and encryption options. Additionally, S3 integrates with AWS Identity and Access Management (IAM) to provide granular access controls and identity management.
Easy Integration: S3 integrates seamlessly with other AWS services, such as CloudFront, Lambda, and API Gateway, to offer a complete solution for image hosting. This integration allows you to build a scalable and secure image hosting service that can handle any traffic load.

Let's dive into some code

Here's a Python code example for setting public access permissions on an S3 bucket using the Boto3 library:

import boto3

s3 = boto3.client('s3')

bucket_name = 'your-bucket-name'

response = s3.put_public_access_block(
    Bucket=bucket_name,
    PublicAccessBlockConfiguration={
        'BlockPublicAcls': False,
        'IgnorePublicAcls': False,
        'BlockPublicPolicy': False,
        'RestrictPublicBuckets': False
    }
)

As a developer working for a website that hosts images, this is just one of the steps in setting up the whole flow. Being a developer, I have also faced the issue of manually doing the whole flow.

Here comes automation (IaC). **Infrastructure as code (IaC) **refers to the process of managing and provisioning infrastructure through code and automation tools. AWS CloudFormation is an IaC service that enables users to create and manage AWS resources using templates and automation.

Here is a CloudFormation template that setups the whole flow for us. The template does the following things

An S3 bucket with public access
Attach the new S3 bucket with a Cloudfront CDN for faster access and caching
Create an IAM user with full access to the newly created S3 bucket

This template solves the burden of setting up this whole flow manually. You just need to run the following from your terminal or upload the template in your AWS console

aws cloudformation deploy --stack-name [STACK_NAME] --parameter-overrides Stage="[ENVIRONMENT]" BucketName="[BUCKET_NAME]" --template-file [PATH_TO_TEMPLATE] --region [REGION] --profile [PROFILE_NAME] --capabilities CAPABILITY_NAMED_IAM

In conclusion, AWS S3 is a reliable and cost-effective image hosting solution that offers a range of benefits, including high scalability, durability, security, and easy integration with other AWS services. If you're looking for an image hosting service that can handle your website's traffic and provide a seamless user experience, then AWS S3 is the perfect solution.

NOTE: I am a developer too. The template can have its fault. Feel free to comment or contact me directly through website/LinkedIn

Hope this was helpful. Thanks

Website: Madhav Bhasin
Github: Madhav Bhasin
Linkedin: Madhav Bhasin