Designing Scalable Backend Architectures With Python

Monolith vs Microservices: The Right Starting Point

The microservices vs monolith debate has a clear answer for early-stage products:

• Start with a well-structured monolith. A monolith is faster to build, easier to debug, simpler to deploy, and sufficient for products up to $1M ARR in most categories.
• A microservice is justified when: a specific service has dramatically different scaling requirements (e.g., video processing), a team boundary requires independent deployment, or a component is reused across multiple products.
• The mistake: building microservices for a pre-revenue product. Microservices require distributed systems expertise, service discovery, inter-service authentication, and observability tooling that adds weeks of overhead with no user benefit.
• The path: Monolith → Modular monolith (clear internal boundaries) → Extract services only when a specific boundary is justified by scale or team structure.

Database Design Principles That Prevent Future Pain

Database schema decisions are expensive to change after users are live. These principles applied at the start save weeks of future migration work:

• Use UUIDs as primary keys, not sequential integers — sequential IDs leak business information (your competitor can estimate your customer count from a user ID)
• Add created_at and updated_at timestamps to every table — they cost nothing and are required for every audit, sync, and debug scenario
• Design for soft deletes (is_deleted flag) from the start — hard deletes break foreign keys and lose data that users will ask for
• Normalise aggressively in the schema, denormalise only when query performance requires it — premature denormalisation creates update anomalies
• Index foreign keys and any column used in a WHERE clause on a table with >10,000 rows

Caching Strategy: What, Where, and When

A well-designed caching layer can reduce database load by 70–90% and response times by 10×. The three layers of caching in a Python backend:

• Application-level cache (Redis): Cache computed results, session data, and frequently read reference data. Use fastapi-cache2 or a custom Redis client. TTL of 60–300 seconds for most use cases.
• Database query cache: PostgreSQL does not have a built-in query cache, but connection pooling (asyncpg pool, PgBouncer) reduces connection overhead by 80%.
• HTTP response cache (CDN): Static responses and public endpoints should be cached at the CDN layer (CloudFront, Vercel Edge). Zero backend load for cached responses.
• What to cache: user preferences, reference data (countries, categories), expensive aggregate queries, external API responses.
• What NOT to cache: user-specific financial data, security-sensitive responses, data that must be real-time.

Async Architecture Patterns

Async Python is a superpower when used correctly and a source of subtle bugs when used incorrectly. These patterns define correct async architecture:

• Background tasks for non-critical work: Email sending, analytics logging, and webhook delivery should never block the HTTP response. Use FastAPI BackgroundTasks or Celery for reliability.
• Task queues for heavy processing: Image processing, report generation, and batch operations belong in a task queue (Celery + Redis), not in the request-response cycle.
• Async database access: Use asyncpg or SQLAlchemy async — never use synchronous drivers in an async FastAPI app. Synchronous DB calls block the event loop and destroy concurrency.
• Concurrency vs parallelism: asyncio handles I/O concurrency within a single process. CPU-bound tasks (ML inference, data processing) require multiprocessing or a separate worker process.

Service Boundaries and API Design

Internal code organisation determines how maintainable a backend is at 100,000 lines of code. These boundaries prevent the big-ball-of-mud pattern:

• Separate route handlers from business logic — routes should call service functions, not contain business logic directly
• Service layer: functions that implement business rules, validate state, and orchestrate data access
• Repository layer: functions that abstract database access — route handlers never touch the ORM directly
• This three-layer pattern (routes → services → repositories) makes every layer independently testable

Implementation Checklist

• Database schema has UUIDs, created_at/updated_at, and soft deletes from sprint 1
• All foreign key columns and WHERE clause columns are indexed
• Redis is configured for session storage and high-frequency reference data caching
• Background tasks (email, webhooks, logging) use Celery or BackgroundTasks, not inline execution
• Async database drivers are used (asyncpg, not psycopg2) throughout
• Route handlers contain no business logic — all logic lives in service layer functions
• A monolith is the starting architecture unless a specific service boundary is justified

Common Mistakes to Avoid

• ✗Building microservices before the domain model is stable — you will spend more time on service coordination than on product features
• ✗N+1 query problem: loading a list of objects and then making a separate query for each object's related data — use SQLAlchemy eager loading or dataloader patterns
• ✗No connection pooling — creating a new database connection per request collapses PostgreSQL at 100 concurrent users
• ✗Synchronous external API calls in the request-response cycle — a 500ms third-party API call adds 500ms to every affected endpoint
• ✗No circuit breaker for external services — a slow third-party API can take down your entire backend if every request waits for it

Frequently Asked Questions