Proposed flow for this scenario
- Latency and dependency requirements
- Concurrency budget
- Selected version or alias
- Environment readiness
- Invocation and useful completion
This flow describes a design to evaluate. The local experiment explores one stated mechanism. Its scope appears with the controls; the proposed services are not provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| Reserved concurrency | A function needs a protected share or a maximum concurrency boundary. | Assuming the reservation warms its environments. |
| Provisioned concurrency | Initialization latency justifies ready environments for the correct version or alias. | Assuming every request uses them or that they are an independent unlimited concurrency pool. |
| Bounded asynchronous work | Customers can wait and downstream capacity needs protection. | Paying for readiness without a measured latency requirement. |
Separate how many can run from how ready they are
LetX has a synthetic interactive status endpoint and an export worker. The endpoint may care about initialization latency; the worker may care more about not overwhelming its database. Write those requirements independently before choosing a concurrency setting.
Reserved concurrency defines an allocation and upper boundary for a function. It does not create pre-initialized environments. Provisioned concurrency addresses readiness for its configured version or alias and adds cost; it is not a cure for slow application logic or an overloaded dependency.
The invocation target matters
In real Lambda, provisioned concurrency is configured for a qualifying version or alias rather than $LATEST. Check that the caller or event source invokes the intended target. Otherwise an apparently correct readiness configuration may not serve that request path.
Capacity beyond the prepared environments and interactions with reserved/account concurrency need a separate review. Inspect actual traffic and configuration rather than assuming the presence of provisioned concurrency guarantees the same latency for every request.
Throttling and timeout require different evidence
A request rejected for lack of available concurrency is different from an invocation that started and exceeded its timeout. Ask whether work began, then inspect its outcome. Raising the timeout does not admit a throttled invocation, and raising concurrency does not shorten one slow call.
The local Lambda console supports selected reserved-concurrency behavior, including a zero setting that disables invocation in the model. It does not model provisioned environments, aliases, initialization latency or a production concurrency scheduler. The backlog experiment below explores assumed capacity only.
Original comparison worksheet
For the LetX worksheet, give the interactive endpoint a latency target and the worker a safe dependency concurrency cap. Describe which setting addresses each requirement and what evidence would indicate the setting is wrong. The worksheet prevents a readiness purchase from being treated as permission to increase pressure on the database.
Run the local zero-reserved-concurrency fault, inspect the refusal and restore the setting. Then explain why that repair says nothing about first-request initialization latency. Preserve separate test criteria for admission, execution duration and useful completion. That makes a later real-world investigation more precise even though the model has no prepared environments.
Changed requirement and a useful check
Question: a LetX function has reserved concurrency but its first request still incurs initialization work. Is the reservation broken? Not from that observation. Reservation and pre-initialization solve different problems. Review the actual latency evidence and suitable readiness options.
Before spending on prepared capacity, measure the latency distribution, cold-start contribution and required availability period. For a worker, test useful completion and dependency saturation at the proposed cap. No local preset result proves a production response-time percentile or calculates the provisioned-concurrency bill.
Practice the supported console workflow
Predict it. Test it. Change one thing.
Local educational model. No account or cloud charges. Nothing is deployed to AWS.
Constant rates; no polling, retries, batch effects or service quotas. This models work conservation.
sim.shahriarlabs.com · Free to explore
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations