Durable state for a stateless platform

We schedule releases for odd hours. A typical one is 3 a.m. The creator is asleep. The video has to go out on time. But the serverless function that does the work may have been cold for hours. It starts with an empty memory space. No local disk. No leftover variables from a previous run. If the code can't see the owner's state, it can't make the right decisions. So we had to design a system that is both stateless and durable.

The answer is per-owner state stored in a database. Every creator on the platform has a state record. It holds their channel settings, their active project, their schedule, and a record of where they are in the release pipeline. At the top of every run, the code reads that record and builds a fresh context. There is no other source of truth. The compute instance is disposable. The state record is not.

Then we write through on every change. When a step finishes, we update the state record immediately. Suppose the audio track is generated. We save that fact right away. If the artwork is approved, that approval is stored before we move to rendering. We never batch updates and flush them at the end of the run. If the instance dies halfway through, any completed work stays completed. A single database write is cheap compared with redoing an entire release.

Why does this matter for a serverless platform? Because cold starts are normal. At 3 a.m., there may be no warm instance waiting. The function is created from scratch. It has no idea what happened yesterday. It cannot rely on anything sticky. So we must rehydrate from the database at the start. This design also keeps the platform horizontally scalable. Any instance can handle any owner because all instance-specific data is loaded at run time.

Rehydration is not a blind read of a blob. The state record is structured. It holds the owner's YouTube channel details, the current video project, the performance data from the last release, and a run token. The run token tells the code whether this is an autopilot run or a manual run. Both types use the same pipeline and the same rehydration path. The difference is only in the trigger. The state itself decides what work is pending.

Durability also makes retries painless. If a run fails at any point, the next run can pick up exactly where the previous one left off. It reads the same state record. It sees which steps are marked complete. It skips those and continues with the rest. We also hold a lock on the state record while a run is active. That prevents two runs from overlapping. A database lock is much easier to manage than a mutex inside a serverless function.

Here is a concrete example. A creator starts a release from the dashboard in the evening. The system generates the audio, creates the artwork, and starts rendering the beat-synced video. Then the instance dies. The state record already shows that the render is not complete. At 3 a.m., the autopilot trigger fires. A fresh instance reads the same record. It sees the audio and art are ready. It starts the render again. The creator never has to re-upload anything or remember what was finished.

That is how we stay stateless and durable at the same time. The compute is disposable. The state is not. A cold instance is just a worker that asks the database for the full picture. So a 3 a.m. release knows everything a hand-started one does. The platform does not trust memory. It trusts the database.