When to use serverless: choose compute from the workload

Proposed flow for this scenario

1. 1Request or event
2. 2Validate and record job
3. 3Queue independent work
4. 4Bounded worker capacity
5. 5Result in durable storage

This flow describes a design to evaluate. The experiment below models queue balance; it does not provision or run these services.

Decision checkpoints

The useful answer starts with constraints

A synthetic LetX export takes a few seconds, can run independently, and arrives irregularly. A function is a reasonable candidate. A synthetic QuantumSketch render holds a native process open for much longer and has different resource needs. Reusing the same compute choice for both would hide the requirement that matters.

Write down typical and worst-case duration, CPU/memory needs, dependencies, arrival pattern, latency target, state ownership and recovery behavior. A workload name such as “API” or “AI” does not answer these questions. Fargate is itself serverless container compute: this decision is about execution models, not whether servers exist.

Separate continuous execution from workflow duration

A standard Lambda invocation has a maximum configured timeout of 900 seconds. A request path can have a shorter limit in an upstream integration or client. Raising the function timeout does not raise every other timeout in the path.

A workflow waiting for a callback is different from one process continuously rendering a video. Current Lambda options include durable workflows and Managed Instances with different behavior and limits. Do not teach “all Lambda work must end in 15 minutes” as a universal rule. Name the compute mode, invocation source and Region, then check its current documentation. This page compares standard function invocations with container workloads, rather than simulating every newer option.

Protect downstream capacity before scaling workers

Suppose the practice export worker starts quickly but its database can safely handle only a bounded number of simultaneous exports. Unrestricted compute growth can turn a burst into database failure. A queue and a capacity limit make the overload visible; they do not increase the database’s capacity.

Use the experiment below to make arrivals exceed completion. Then increase capacity within your assumed downstream budget. Watch whether the backlog stabilizes. This models queue balance, not actual Lambda concurrency, ECS scheduling or autoscaling delay. For a real workload, inspect oldest-job age, useful completion rate and dependency saturation.

Put state outside a replaceable worker

A job identifier, status and final artifact must survive replacement of the process that generated them. In this practice design, store input/output in durable storage and record progress independently of worker memory. A container’s long lifetime does not turn its memory into a backup.

For retried work, choose a stable job key and a conditional completion record. Avoid publishing the same export twice because two deliveries both arrived. Use scoped workload roles and define which objects the worker may read or write. The relevant lesson is the boundary between identity, state and execution.

Compare the complete operating cost

Estimate compute, idle or warm capacity, requests, data transfer, networking, logging and the data services for the same workload and Region. Use explicit traffic and duration assumptions. Do not declare one service cheaper from a request count alone.

For this platform, the current simulations and public lessons already run in a browser and static deployment. A runtime backend would add work without improving those features. A future newsletter or server-backed collaboration feature should justify its own endpoint and data handling. That product decision is separate from the synthetic AWS architecture taught here.

Change the constraint and defend the new choice

Original practice question: the same export now requires an uninterrupted 25-minute process and depends on an existing container image. Which earlier assumption changed?

Answer: the task no longer fits one standard Lambda invocation. An asynchronous container task becomes a candidate; splitting the work is another candidate only if it preserves correctness. A queue solves request waiting and overload, but does not remove a worker’s execution limit. Managed Instances or other compute options require a separate review of their supported limits and cost.

Sources and scope

Reviewed against these official references. The model’s supported scope appears alongside its controls.

• AWS: Fargate or Lambda decision guide
• AWS: Lambda quotas and compute-mode limits
• AWS: designing Lambda applications
• AWS: Lambda best practices
• AWS: ECS service auto scaling