Execution Ceiling
also called Platform Hard Limit, Invocation Limit
The absolute platform bounds on one unit of work - duration, memory, payload, disk, concurrency - which eliminate execution models before any cost comparison is relevant.
A nightly reconciliation job takes about 90 minutes on a developer machine. The team plans to run it as a single function invocation, because the rest of the service runs that way. As of 2026 the common per-invocation runtimes cap one execution at around 15 minutes, with memory in the low gigabytes, payloads of a few megabytes, and little local disk.
The job does not run slowly. It is killed at the ceiling, mid-write, leaving either a partial summary that looks complete or nothing at all - and the retry policy runs the same doomed execution twice more. The symptom reported next morning is "the report is wrong", not "the job failed", which is how a limit documented on one page costs a day.
An execution ceiling is not a tunable. No setting buys the 91st minute, which is what makes these limits the first filter in an execution-model decision rather than an afterthought.
Why it matters
The serverless-versus-containers discussion is usually conducted in cost terms: break-even utilisation, idle capacity, per-invocation pricing. That arithmetic only matters among options that can run the workload at all. Ceilings eliminate candidates; economics ranks the survivors, and the wrong order produces a design that is cheaper on a spreadsheet and does not work.
A limit on one unit of work is also a standing argument for partitioning, and the partition key becomes part of the architecture rather than a detail.
Implementation patterns
- Check five numbers before design: duration, memory, request and response payload, local disk, and concurrency. The last one matters because a few hundred simultaneous invocations can exhaust a database's connection limit - a ceiling arriving from the other side.
- Partition under the limit with a coordinator. 24 hourly slices of a 90-minute job are about four minutes each and run in parallel, which is faster than the original.
- Make each slice idempotent and individually retryable, with a final step that fails loudly if any slice is missing. Without that check, a partial result is indistinguishable from a finished one.
- Record the ceiling and the margin in the decision record - 11 minutes against a 15-minute limit is an incident waiting for a slow dependency day.
Industry example
Large-artifact distribution is where payload ceilings bind hardest, and the answer is partitioning plus a completeness layer. Hugging Face's Xet-backed storage path splits files with content-defined chunking and bundles deduplicated chunks into blocks of up to 64 MB, so a multi-gigabyte model file is never one transfer; a published example stores the gemma-2-9b-it-GGUF repository as 1515 unique blocks totalling about 97 GB against 191 GB originally, and older clients keep working through an LFS bridge.
The shape generalises: units that fit the ceiling, a manifest saying what a complete set looks like, and a compatibility path for callers you cannot upgrade.
Failure scenarios
- Silent truncation at the duration limit, leaving a partial write that consumers treat as authoritative.
- Retry amplification: the platform retries the killed invocation, so the same impossible work runs three times and triples the read load.
- Connection exhaustion under scale-out, where 1800 concurrent invocations meet a database permitting 400 connections and errors surface in unrelated services.
- A payload ceiling discovered by the largest customer, because every test tenant was small.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Partition under the ceiling | Parallelism for free, per-slice retries, one execution model across the service | A coordinator, idempotent writes, and a completeness check that must fail loudly |
| Change execution model | No ceiling to engineer around and a single process to reason about | Always-on capacity to pay for and a second deployment shape to operate |
When not to use it
Do not engineer around a ceiling for work that cannot be partitioned. A single sort over a full day's data, or one transaction that must be atomic, is a container-shaped job; spending a sprint on a coordinator so it can stay on the same execution model as the API is complexity bought for consistency of style.
Nor are ceilings an argument against per-invocation platforms in general. For work that partitions naturally the ceiling is a guardrail - it pushes you towards small idempotent units, the shape you want anyway, and the parallelism is free.
Interview question
Q: A team wants to move a nightly 90-minute batch job onto the same function platform as its API, for consistency. How would you evaluate that, and what would you need to see before agreeing?
What a strong answer covers: checking ceilings first - duration, memory, payload, disk, concurrency - and recognising that the 15-minute cap rules out the single-invocation design before cost is discussed; a partition key with arithmetic showing each slice fits with margin; idempotency and a completeness check; the connection-limit consequence of parallel slices; and the condition for running a container instead.
Quick check
Quiz: A function-based job sits at 11 minutes against a 15-minute ceiling. Acceptable? No - there is no margin for a slow dependency day. Either partition it or move to an execution model whose limit you set.
Flashcard: In what order do you evaluate serverless against containers? - Ceilings, then the shape of the work, then the economics. Limits on duration, memory, payload, disk and concurrency eliminate options; utilisation only ranks what is left.