Sources and further reading

Practices in this skill were cross-checked against the following, plus the official documentation. Where guidance conflicted, the official docs and the concurrency material won.

Concurrency (the async rules)

The async def versus def guidance, the threadpool default of roughly 40, and the "one blocking call collapses concurrency" failure mode come from:

• Concurrency and async / await, FastAPI docs
• Behind the Scenes: Concurrency in FastAPI, Viktor Bubanja
• What actually blocks your FastAPI event loop
• Fixing FastAPI Throughput Without Going Fully Async, DPDzero
• Asynchronous vs. Synchronous Functions in FastAPI, Leapcell

Structure and layering

The router / service / repository split and feature-first grouping:

• FastAPI Project Structure: Production Guide 2026, Zestminds
• Production-Ready FastAPI Project Structure (2026 Guide), DEV
• FastAPI Best Practices: Building Production-Ready Python APIs in 2026, Pratik Pathak
• FastAPI Best Practices for Production, FastLaunchAPI

Testing

ASGITransport, dependency overrides, containerised databases, and the testcontainers alternative:

• Developing and Testing an Asynchronous API with FastAPI and Pytest, TestDriven.io
• Containerised Testing: Running FastAPI Database Tests Locally with Docker and PostgreSQL
• Testing FastAPI with testcontainers in GitLab
• testcontainer-fastapi-demo
• pytest-docker
• Integration testing for a bunch of services with Pytest and Docker Compose

Observability

Request ids, JSON logs, the adoption order, and OpenTelemetry:

• Implementing OpenTelemetry in FastAPI, SigNoz
• Operations-Friendly Observability: A FastAPI Implementation Guide
• Production-Grade Logging for FastAPI Applications
• A Complete Guide to Integrating OpenTelemetry with FastAPI, Last9

Deployment

• FastAPI Deployment Guide for 2026, Zestminds

A note on the guidance that is not from these

Several specifics here come from operating services rather than from the articles above, and are the parts most worth arguing with:

• Migrations must not run in lifespan. Widely done, and it is a race as

soon as there is more than one replica.

• Liveness must not check the database. Conflating the two probes turns a

brief database blip into a full restart storm.

• Integration-heavy rather than unit-heavy. This inverts the usual pyramid.

It is right for services that are mostly HTTP-to-database glue, and wrong for a library or a computation-heavy domain.

• Authorization tests for every endpoint. Rarely mentioned in structure

guides; consistently the gap that matters.