backend-architecture

Backend Architecture — the Solutions Architect Baseline

The most common mistake in vibe-coded backends is treating the application server as if it were a desktop computer: state lives where the code lives, the disk is permanent, restarts are exceptional, one instance runs forever. None of that survives contact with production.

This skill is the architectural baseline that makes a backend production-ready. It is not security-specific — but a backend that loses data, drops jobs, or rolls back to a half-state during deploys is also a backend whose incident-response surface looks much larger than it should. Pairs with the hardening skills, but operates at a different layer.

When to invoke

• "User uploads disappeared after we redeployed"
• "The site went down during deploy and we lost the in-flight orders"
• "I need to scale to a second server but nothing works when there are two"
• "We're moving from prototype to production"
• "We're handing off the codebase to a team that has to run it"
• Designing a new backend from scratch and you want the decisions correct on day one
• Reviewing an inherited backend before scaling user count or revenue

The single most important rule

App servers are cattle. State lives elsewhere.

Any data that must survive a deploy, reboot, container restart, or instance replacement is state. State does not belong on the app server's local disk, in its memory, or anywhere bound to the instance's lifetime. It belongs in a system designed for durability.

This rule, followed consistently, eliminates 80% of "where did my data go?" incidents.

The state-placement decision matrix

For every piece of data your app handles, decide where it lives before writing the code:

Data type	Right place	Wrong place
User-uploaded files (images, PDFs, docs)	Object storage (S3, R2, B2, Spaces) behind a CDN	App server's uploads/ directory
Generated thumbnails / derivatives	Object storage, or regenerated on-demand from originals	App server's filesystem
Database rows (orders, users, posts)	Managed Postgres / MySQL, or a dedicated DB VM with backups	SQLite next to the app code
Session data	Redis, managed cache, or DB-backed sessions	In-process memory (Map, WeakMap)
Cache (computed data, hot reads)	Redis / Memcached / Cloudflare KV	Local memory if and only if loss-tolerant
Background-job state	Persistent queue (BullMQ + Redis, AWS SQS, GCP Pub/Sub, NATS JetStream)	setTimeout / setInterval in the web process
Logs	Centralized log destination (Loki, hosted, syslog forwarding)	App server's /var/log only
Secrets	Env vars from a secret manager, or runtime injection	.env checked into the image / repo
Search index	Managed search (Algolia, Meilisearch, Elasticsearch, Postgres GIN)	Recomputed from DB on every request
Email-sending	Transactional ESP (Postmark, Mailgun, SES, Resend)	Direct SMTP from the app server in production