Why should request state survive after the request is finished?

In most server environments, a request creates mutable application state that persists beyond the life of the request itself. This happens because the process that handles the request continues to run, carrying the state with it. This approach is efficient and familiar, but it means that state's lifetime is determined by where it resides, not by its purpose.

Usai aims to separate these two aspects. The issue is that many variables and objects created during a request continue to exist even after the request has finished, leading to unexpected behavior and potential bugs. While it's true that platforms like AWS Lambda and Cloudflare Workers reuse execution environments for speed, they advise against storing potentially sensitive data in the execution environment.

Usai takes a different approach, proposing that the distinction between persistent infrastructure and application state should be enforced at the runtime level. In Usai, the application is divided into three layers, each with its own lifetime: the persistent runtime, which runs throughout the process; immutable application definition, built once per deploy; and the execution world, which exists for the duration of one unit of work, such as a request, task, or timer.

Each request or task gets a fresh execution world, ensuring that state is ephemeral by default. While there are cases where some data should persist, like database connections or WebSocket connections, these are declared as persistent on purpose. Usai's runtime cancels any asynchronous work that outlives its execution world, preventing potential issues that could arise from lingering state.