Skip to content

Why I Chose FastAPI, PostgreSQL and Redis/Celery

· 1 min read · 0 views

Backend EngineeringFastAPISystem DesignSoftware Architecture

TimeSense uses FastAPI, PostgreSQL and Redis/Celery, but not because they form a fashionable stack.

Each component solves a different problem.

FastAPI provides typed API contracts and works well with asynchronous integration and LLM calls.

PostgreSQL is the authoritative store for users, tasks, events, permissions, feedback, entitlements and audit records.

Redis and Celery handle work that should not block an API request: synchronization, notification orchestration, recommendation jobs, weekly insights and scheduled refreshes.

I considered simpler architectures, including running background work directly inside the web process. That would have reduced the initial number of components, but it would also mix request handling with long-running and scheduled work.

The tradeoff is greater operational complexity.

The benefit is clearer responsibility, safer background execution and a backend that can evolve without making every feature part of one process.

A stack is valuable only when its boundaries remain understandable.

Why I chose FastAPI, PostgreSQL and Redis/Celery: a typed async FastAPI service on PostgreSQL as the source of truth, Redis for cache and queue, and Celery for background jobs, each owning a different responsibility. Rejected: running all work inside the API process.

Originally posted on LinkedIn.