03 · Why the edge

The engine runs at the edge — the code does not live on one server but is replicated across hundreds of locations and executes in whichever is nearest the reader. For a site whose readers sit on three continents, that is the difference between an immediate answer and a noticeable wait.

The billing model is such that, at the traffic a literary project typically sees, the bill is zero. Not “small” — zero. That satisfies the third condition from the first entry in a way no server rented by the month ever will.

The bill is paid in constraints, and they deserve an honest listing, because they shaped the rest of the architecture. There is no writable file system. There are no processes living between requests, so there are no background jobs in the classical sense. There is a CPU time limit per request. There is a limit on the size of the code bundle.

Each of those constraints returns in later entries in this series as the cause of a specific decision. No file system forced the content–database split. No background processes forced notification delivery to ride on requests that arrive anyway. The bundle size limit forced pagination, because sending an entire archive in one response stops working at a sufficiently large archive.

It is worth saying plainly, because it sounds like a drawback and is an advantage: the platform's constraints acted like a reviewer who does not wave lazy solutions through. Many of the things this engine does well, it does well because doing them badly simply would not have worked.