Principle: Prefer stateless services

Stateful services are hard to scale horizontally, hard to recover from failures, and create sticky sessions that complicate load balancing.

Design services to be stateless — all state lives in external stores:

1. Session state -> External store:

Bad: In-memory session store (lost on restart)
Good: Redis, database, or JWT tokens

1. File uploads -> Object storage:

Bad: Local filesystem (not available on other instances)
Good: S3, GCS, or MinIO

1. Cache -> External cache:

Bad: In-process cache (different per instance)
Good: Redis/Memcached (shared cache)

1. Background jobs -> Job queue:

Bad: In-memory job list (lost on restart)
Good: Redis Queue, Celery, SQS

1. Configuration -> Environment or config service:

Bad: Local config file modified at runtime
Good: Environment variables, config service

Benefits of stateless:

• Scale horizontally: add instances behind load balancer
• Recover from crashes: restart anywhere, nothing lost
• Deploy easily: any instance can handle any request
• Test simply: no state to set up or clean up

Exception: Some state is OK to keep in-process:

• Read-only cached data with TTL
• Connection pools (to databases, not to clients)
• Compiled templates or regex patterns

Stateless services are cloud-native. They can be scaled, restarted, and deployed independently without data loss or session disruption.