Why: the goal or problem

Imagine a festival site with schedules and occasional saves. An always-running app would sit idle through most of this read-heavy day.

How: work toward a solution

Read article invokes a handler. Save Festival Schedule invokes another handler and writes an external store. Repeat Save keeps one record under the example’s reader/article key. Fail next save returns failure without changing storage. Restart handler discards execution state but retains that record. Reset or reload clears this page-memory simulation, including its illustrated store.

Invocation lifetime and duplicate handling

Concept simulation

Serverless functions

Read the public article, then save Festival Schedule. Repeated requests share Mina / Festival Schedule.

01 · Managed execution

Browser → function invocation → article HTML

02A · Save invocation

Mina / Festival Schedule

02B · Repeated invocation

Mina / Festival Schedule

Execution generation: 1 · Calls in this generation: 0

↓ Same key → one record

Waiting

The store is simulated in page memory. Restart preserves it; Reset or reload clears it. Deduplication is authored application logic.

Execution boundary
Request → managed invocation → external store. Instance memory may disappear between invocations.
State and responsibility
Platform manages servers; application owner manages retries, access, monitoring and durable records.

A fictional demo within this article. Reset or reload restores its initial state.

What: the concept

Serverless functions run managed handlers in response to events or requests. The platform manages servers; application correctness still belongs to the developer.

Design duplicate handling and persistence explicitly; never assume a warm instance.

Source