backend-architecturelisted

# 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 des