Backend workloads need different execution models. Interactive APIs fit HTTP services or functions, independent jobs fit queue consumers, and dependent processes fit durable workflows. Scheduled work needs a trigger and recovery plan; realtime work needs connection management; intensive computation needs suitable hardware. Vercel Functions are one option for Python applications.
These categories overlap. Nightly model training can be scheduled, coordinated by a workflow, and executed on GPU compute. Separate the trigger that starts work from the mechanism that tracks it and the compute that performs it.
Copy link to heading1. Keep interactive APIs within the response budget
With an interactive API, a caller waits while the application performs its work. Loading an account summary, checking permissions, or calculating a small estimate can fit this model. The request reaches an HTTP service or request-triggered function, which runs the application logic and returns the result.
The relevant budget includes everything on that path. Even a short calculation can produce a slow response if it waits on several database queries. Measure with representative inputs and concurrent requests so that an empty development database doesn't hide the production workload.
On Vercel, the Python runtime runs ASGI and WSGI applications as Functions, with framework detection for FastAPI, Flask, and Django. Clients can receive streamed output as it becomes available while the executing code remains subject to Function resource limits.
If an export takes longer than a person should wait on the page, accept it as background work and return a job identifier. Store enough information for the interface to retrieve status later. Processes that must remain alive between requests need an execution environment with that lifecycle, even when their public interface is an HTTP API.
Copy link to heading2. Dispatch independent background jobs through a queue
Using a queue separates accepting work from running it. Consider customers requesting report exports after a monthly close. The API can record each request and enqueue a job while consumers generate the files. The code that receives a queued message and performs its work is the consumer.
This separation gives you control over how much work runs concurrently. If exports arrive faster than the database can support them, leave some pending and limit consumer concurrency to a sustainable rate. The tradeoff is visible waiting time, so the application should show whether an export is queued, running, or ready.
Vercel Queues organizes messages into topics with independent consumer groups. Delivery is at least once, with retries and visibility timeouts. If a consumer fails to acknowledge completion before its visibility timeout expires, the message can be delivered again. Design consumers to be idempotent, meaning that processing the same request again does not create an unwanted additional result. Export jobs could write output under a request-specific key and prevent duplicate completion records with a unique database constraint on that identifier.
Consumers can run as functions or continuous workers, depending on the queue integration and the job's requirements. For example, Vercel's Celery integration runs Python tasks in private, queue-triggered Functions, without a continuously running Celery worker process. If one job must wait for another job's result or a person's approval, the application also needs to track that dependency.
Copy link to heading3. Preserve dependent steps with a durable workflow
As a process moves through dependent steps, a durable workflow tracks its progress. Approving an expense might involve validating a submission, waiting for a manager, and then updating an accounting system. The process needs to remember which expense is waiting and what has already completed, even if the application restarts during the wait.
Workflow engines persist that progress and coordinate subsequent execution. Waiting for approval can span far longer than the code that validates the expense. Treating the entire process as one open request would tie its lifetime to a connection and an executing process.
Vercel Workflows stores process state and event logs, supports pausing and resuming, and recovers across crashes and deployments. Functions execute the workflow and step code, while Queues provides reliable enqueuing. Overall workflow duration is distinct from the duration of any individual step. Expensive calculations inside a step still need compute that can accommodate them.
Recovery also needs to account for external effects. If an accounting update succeeds but its confirmation is lost, a retry must recognize the earlier update. Use a stable operation ID where the receiving system supports deduplication, or check its stored result. When choosing between queues and workflows, decide whether to dispatch independent work or preserve progress across dependent steps.
Copy link to heading4. Schedule batch work with a recovery plan
Scheduling determines when work starts, while a batch groups work for processing, such as reconciling the previous day's transactions. You can use a scheduled function for a bounded reconciliation. Historical backfills may need partitioned jobs and a record of which partitions have finished.
Define the batch's scope before starting it. For a reconciliation, record the time window being processed so that a retry reads the same window. Save progress at a useful boundary, such as an account or partition, and decide whether a later scheduled run should wait, skip, or process a separate window when an earlier run is still active.
Vercel Cron Jobs starts work with an HTTP GET to a configured path on the production deployment. The endpoint can perform a bounded job or initiate queued work. Receiving that scheduled request does not establish that the entire batch completed or that a partial failure will recover.
As the dataset grows, partitioning can keep each unit within the worker's capacity. Add workflow coordination when a final operation must wait for all partitions, such as publishing a report only after every account has reconciled.
Copy link to heading5. Design realtime connections for reconnection
Realtime workloads keep a channel open so the application can exchange updates without a new request for every message. In a collaborative editor, clients can send document changes over a WebSocket connection. Choose a service that supports the protocol and plan how clients recover from a lost connection.
After reconnecting, the client needs to discover changes it missed. You might store document revisions and let the client request updates after its last known revision. If collaborators connect to different server instances, those instances also need a shared way to distribute changes. Keeping the document only in one process's memory leaves other instances without an authoritative copy.
Vercel Functions support WebSockets, including Python framework integrations. Each connection stays pinned to one Function instance, but a reconnect can reach another instance. Persist session data that must survive that transition outside the connection's local memory.
Periodic status requests may be enough for a page that only checks whether an export has finished. Bidirectional editing needs a fuller protocol for sending changes and resolving concurrent updates, whether you operate it yourself or use a managed realtime system.
Copy link to heading6. Size compute-intensive jobs for their hardware
Compute-intensive jobs spend substantial resources doing calculations. Simulations may need CPU time and memory; model training may need GPUs. Measure requirements with representative workloads and the largest inputs you plan to support. Language alone does not determine hardware needs.
When the calculation exceeds the API runtime's capacity, give it a separate worker. The API can submit a job reference, and the worker can store its result for later retrieval. Modal functions support GPU allocation, making them one option to evaluate when a job needs GPU computation.
Queues and workflows can coordinate that worker without changing its resource requirements. If a job cannot fit in memory, adding retries will repeat the failure. Reduce the working dataset, partition the calculation where possible, or select compute with sufficient capacity.
Copy link to headingCheck the runtime independently of the packaging
Container images package applications and their dependencies, but their hosts determine when processes start and how long they run. Vercel Container Runtime, currently in beta, runs OCI container images as Functions. Packaging an application this way does not make it an always-running server.
Check the current Vercel Function limits for duration, memory, and packaging before assigning work to a Function. Limits depend on the runtime and plan. The same assessment applies to a request handler, queue consumer, or executing workflow step. For work that exceeds those constraints, divide it into bounded units or use compute that fits the whole operation.
Copy link to headingCombine the models in a document-review application
Consider a proposed document-review application with a Next.js interface and Python API. The API stores a job record after the file reaches persistent storage, then enqueues extraction work using the document's identifier. The extraction worker reads the file and stores the extracted fields. The stored job record lets the interface retrieve status through the API after a user reopens the page.
If extraction is the only required operation, an independent queued job can be enough. When a reviewer must approve the extracted fields before another system receives them, introduce a workflow to track that approval and the subsequent update. The worker's resource requirements remain a separate decision, especially for large files or GPU-based processing.
Vercel Services can combine the frontend and Python backend in one project. Each component builds separately and can use a shared domain. Keep application state in explicit storage and pass identifiers between components; a shared project does not imply a shared process or shared memory.
Copy link to headingFrequently asked questions
Copy link to headingIs a backend the same thing as an API?
No. Application components use an API to request data or actions. Behind that interface, the backend contains the server-side logic and may also include background workers or scheduled processes that run without a user request.
Copy link to headingDoes background processing require an always-running server?
No. Queues can invoke functions as jobs become available, provided each job fits the function's resource limits. Vercel's Celery integration follows this model with private queue-triggered Functions. If the workload requires a process that stays alive between jobs, a continuous worker remains an option.
Copy link to headingAre containers and serverless mutually exclusive?
No. Containers describe how you package code and dependencies, while serverless describes how the platform manages execution resources. Vercel Container Runtime, currently in beta, runs container images as Functions. The image format does not determine the lifetime of the process or remove the host's execution limits.
Copy link to headingCan one application use several execution models?
Yes. Within one application, you can answer interactive requests through an API, send independent work to queue consumers, and track approval processes with workflows. You can start those jobs with a scheduler and use specialized workers for calculations that need different hardware. Choose each model for the work it performs and keep shared progress in persistent storage.