8:40Vercel
Log in to leave a comment
No posts yet
When working with serverless functions, you eventually hit the wall of execution time limits. Vercel Workflows solves this by turning asynchronous functions into stateful processes. The key here is to eliminate uncertainties—like database writes or random functions—inside the orchestrator function. All side effects must be confined within step.run blocks to prevent the system from becoming inconsistent.
Declare use workflow in the function that controls the overall logic and use it only for flow management. Define actual API calls or DB operations as independent steps. When passing data to the next step, select only the necessary data to save on log storage costs. Designing your code this way ensures that even if a task fails midway, you don't have to start from scratch; you can simply resume from the point of failure.
In distributed systems, network errors can cause the same step to execute twice. In a payment system, this is a disaster. Vercel Workflows provides a unique stepId for each step. When integrating with services like Toss Payments or Stripe, using this ID as an idempotency key can prevent duplicate payment accidents.
Implement a pattern in your code to check if a transaction has already been processed before writing data. You can assign the ID extracted via getStepMetadata() to the idempotency headers of external service requests. Design the system to return immediately if a transaction has already been handled. Establishing this structure alone can reduce unnecessary API calls and save more than 20% in infrastructure costs.
Vercel's serverless functions typically shut down after 1 to 15 minutes. However, using step.sleep allows you to easily handle scheduled tasks that take days. When this function executes, the workflow state is recorded in storage, and the function terminates immediately. No computing costs are incurred while waiting.
For example, if you need to send a survey email three days after a payment is completed, a single line of await step.sleep('3 days') is sufficient. Since you don't need to manage separate crontabs or schedulers, you can reduce operational time by about 2 hours per week. The cost of running a server 24/7 also disappears.
The repetitive cycle of deploying and fixing kills development speed. By leveraging Vercel CLI features, you can test locally without uploading to the cloud. If you need to receive external webhooks, use tools like ngrok to expose your localhost to the outside world.
By running vercel dev and registering the ngrok URL in your Stripe webhook settings, your local code can receive external events in real-time. Validating failure scenarios before deployment can double your development speed and reduce time wasted on environment variable configuration errors.
You can face a cost bomb if infinite retries occur due to API rate limits or temporary network failures. You must respond differently depending on the nature of the error. Permanent errors like authentication failures should stop immediately, while transient issues like network glitches should be retried over time.
Apply an exponential backoff formula that gradually increases the retry interval:
Limit the maximum number of attempts by setting maxRetries: 3 in the step.run function. As the system recovers automatically, service availability increases, and overcharging due to infinite loops is blocked in advance.
Vercel Workflows includes 50,000 step executions by default on the Pro plan. Beyond that, it costs approximately $2.50 per 100,000 steps. Storage costs for long-term waiting are very affordable at $0.00069 per GB-Hour.
| Category | Hobby/Pro Allowance | Overage Rate |
|---|---|---|
| Workflow Steps | 50,000 steps | $2.50 per 100,000 steps |
| Workflow Storage | 720 GB-Hours | $0.00069 per GB-Hour |
| Serverless Function | 1,000 GB-Hours | $0.60 per GB-Hour |
This is overwhelmingly more economical than the effort of building and managing complex message queues yourself. By properly combining idempotency guarantees and exponential backoff, you can achieve production-level reliability without the burden of infrastructure management. For solo developers who want to focus solely on business logic, there is no more rational choice than this.