Developers transitioning from long‑running backends to Vercel's serverless model often encounter unexpected behavior. Unlike traditional Golang or Node.js servers that maintain a persistent process, Vercel's /api routes are instantiated per request and terminated immediately after the response, making the global execution context ephemeral. This volatility prevents reliance on in‑memory state; global variables are isolated per invocation and may disappear during cold starts, requiring external stores such as Redis or PostgreSQL for durable data.

Concurrency is handled by horizontal scaling—Vercel spins up many function instances under load, which can overwhelm databases unless connection pooling solutions like Prisma Accelerate or Supabase Pooling are used. Background tasks cannot continue after res.send() because the runtime is paused or killed, so developers must complete all work before responding or delegate to queue services like Upstash Workflow. Additionally, persistent connections such as WebSockets are unsupported, necessitating third‑party real‑time services (Pusher, Ably).

Understanding these architectural constraints is essential for building reliable, scalable applications on Vercel, Netlify, Cloudflare Pages/Workers, or AWS Amplify.