Let’s look at three real-world failure modes caused by bad production-settings.
Catastrophe 1: The CORS Nightmare
A team deploys a frontend on https://app.domain.com and an API on https://api.domain.com. In development, they disable CORS (Cross-Origin Resource Sharing). They launch with CORS_ORIGIN='*' in production. Suddenly, any malicious website can call their API using a user’s session cookie. Fix: Production-settings must lock CORS to explicit domains: CORS_ORIGIN='https://app.domain.com'.
Catastrophe 2: The Memory Leak
A Docker container runs a Node.js app. The developer forgets to set --max-old-space-size. The app runs fine for 6 hours, then crashes with FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed. Fix: Always cap memory in production-settings to 80% of the container limit.
Catastrophe 3: The Timezone Trap
An AI model training pipeline runs daily at midnight UTC. The business user in PST expects 4 PM. The production-settings for cron scheduling use a different timezone than the database's NOW() function. Data misalignment causes incorrect recommendations. Fix: Standardize all production-settings to UTC and convert only at the presentation layer. production-settings
# Nginx production settings
worker_processes auto;
worker_connections 4096;
gzip on;
gzip_types text/plain text/css application/json application/javascript;
client_max_body_size 10M;
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mycache:10m;
-- postgresql.conf production tweaks
max_connections = 200
shared_buffers = 25% of RAM
effective_cache_size = 75% of RAM
work_mem = 4MB -- per operation
maintenance_work_mem = 64MB
wal_buffers = 16MB
max_wal_senders = 5
-- Connection pooling (PgBouncer recommended)
[databases]
mydb = host=localhost port=5432 dbname=mydb
[pgbouncer]
pool_mode = transaction
default_pool_size = 20
max_client_conn = 1000
// Winston production config
const winston = require('winston');
const logger = winston.createLogger(
level: 'info',
format: winston.format.json(),
transports: [
new winston.transports.File( filename: '/var/log/app/error.log', level: 'error' ),
new winston.transports.File( filename: '/var/log/app/combined.log' ),
new winston.transports.Console( format: winston.format.simple() )
]
);
// Health check endpoint
app.get('/health', (req, res) =>
const health = status: 'up', timestamp: Date.now() ;
// Check DB, cache, etc.
res.status(200).json(health);
);
Local development often uses lightweight databases like SQLite. Production requires a database engine capable of handling concurrency and high load, such as PostgreSQL or MySQL. Let’s look at three real-world failure modes caused
The primary distinction in production settings lies between discrete and process manufacturing.
The Hayes-Wheelwright Matrix provides a framework for categorizing production settings based on volume and variety:
In production, logs should be structured (usually JSON) rather than plain text. This allows tools like Datadog, Splunk, or ELK Stack to parse and search them efficiently. What NOT to log:
What to log:
What NOT to log:
