Django + Postgres + Celery Architecture

What this diagram shows

This diagram shows a production Django application stack with asynchronous task processing. Request flow enters through nginx (reverse proxy), routes to gunicorn workers running Django, which reads from a Postgres primary database and writes to replicas. Long-running tasks are offloaded to Celery workers via a Redis message broker. Celery workers poll Redis for jobs, execute them independently, and store results. Sentry captures application errors across Django and Celery. The architecture separates synchronous web requests from asynchronous background work, enabling the web layer to remain responsive while heavy computation happens in worker pools.

Key components

• nginx — Reverse proxy and load balancer that terminates SSL connections and distributes incoming HTTP requests to gunicorn worker processes.
• gunicorn — Application server that spawns multiple worker processes to run Django request handlers and enforce concurrent request limits.
• Django application — Web framework that handles HTTP requests, validates data, queries the database, and enqueues Celery tasks for asynchronous work.
• Postgres primary — Authoritative database that accepts all write operations from Django and replicates changes to read replicas.
• Postgres replicas — Read-only database copies that serve SELECT queries to distribute load and allow reads during primary maintenance.
• Redis — In-memory message broker that stores Celery task queues and allows task acknowledgement and result caching.
• Celery workers — Separate processes that consume tasks from Redis, execute them asynchronously without blocking web requests, and store results back in Redis.

When to use it

Use this architecture when your Django application needs to handle background jobs like email sends, image processing, or batch data operations without delaying HTTP responses. It suits teams comfortable operating multiple systems and is appropriate once synchronous request handling becomes a bottleneck. This stack handles moderate to high traffic (thousands of requests per minute) and is not the right choice for applications that are primarily synchronous or where every operation must complete within a single request cycle.

Common mistakes

• Routing all database queries including heavy reports to the primary instead of sending read-only queries to replicas, causing write locks to back up web requests.
• Enqueuing Celery tasks without setting a time limit or retry strategy, leading to hung workers and stuck tasks that never complete or fail gracefully.
• Omitting error tracking for Celery tasks so background job failures go unnoticed while users see partial results or missing data in the application.

Adapting it to your system

Identify your long-running operations (reporting, file processing, notifications) and move them into separate Celery task functions rather than keeping them in Django views. Replace Redis with RabbitMQ if you need message persistence or more complex routing. Adjust gunicorn worker count based on your CPU cores and expected concurrent requests, and set the Postgres replica count according to read load; most teams need one or two replicas. Modify Sentry integration to capture Django signals and Celery task success/failure hooks, then tune alert thresholds for your error volume and acceptable downtime.