How a document saves itself without losing your last sentence

There is no Save button in Nemi Docs. You type, and the document is stored. That sentence hides a real design problem: save too eagerly and a busy document hammers the database with a write per keystroke; save too lazily and a crash, a redeploy or a closed laptop takes your last sentence with it.

This post walks through the timers that decide when your words reach the database, why there are four of them rather than one, and the guard that refuses to save a document that has suddenly gone blank. Type into the figure below and you can watch them work on your own keystrokes.

Where does a keystroke go?

A Nemi document is a live, shared object. Each open copy in a browser keeps its own version, and the server keeps one more, called the room, which every editor of that document is connected to. Your keystroke changes your copy first, so typing never waits on the network. From there it has two journeys left: from your browser to the room, so other people see it, and from the room to the database, so it survives.

Each journey has its own timer. Your browser collects edits and sends them once you have been quiet for 250 ms, so a burst of typing becomes one request instead of twenty. The room then waits until it has been quiet for 900 ms before writing to the database, so a paragraph becomes one write instead of one per word. A big paste skips the first wait entirely: anything over 48 KB leaves at once and asks to be saved straight away.

What if you never stop typing?

Quiet timers have a flaw that is easy to miss. They only fire when you stop. Somebody transcribing an interview might not leave a 900 ms gap for minutes, and with quiet timers alone, nothing they typed in those minutes would reach the database until they paused. A crash in that window would lose all of it.

Two timers close that gap, one on each side. In the browser, the first edit that has not yet been confirmed as stored starts a 3 second checkpoint. When it fires, the browser sends whatever it holds and asks the room to write to the database now, not later, and to say when it has. In the room, the first edit of a burst starts a 4 second maximum wait, which forces a save however busy the document is.

The result is a bound that does not depend on how you type. Pause, and your words are stored 1.15 seconds after your last keystroke. Type without stopping, and the timers hold nothing longer than 3 seconds. On a real connection add a round trip to both, and while you are offline the checkpoint simply waits for the network to come back, then sends everything in one go. In the model the room's own maximum wait never fires first, because the browser's checkpoint always gets there sooner. It is there for edits that reach the room with no checkpoint behind them, such as a browser whose checkpoint request never arrived.

What happens when you close the tab?

Leaving is the moment edits are most at risk, so it gets its own path. When a tab is hidden or closed, the browser hands whatever it is still holding to a delivery mechanism built for exactly this, one that finishes sending after the page is gone, and the request asks the room to store it immediately. That mechanism has a size limit of its own, which is the other reason a large paste is sent at once rather than waiting: it keeps what is left over at closing time small.

If anything is still unconfirmed when you try to leave, the browser shows its standard “leave this page?” warning. The chip in the editor reads Saved only once the server has confirmed the words are on disk, not when they were merely sent, so the warning and the chip agree with what is actually stored.

Why would a save be refused?

One kind of save is refused on purpose. When a document opens, the editor starts empty and is filled with the stored content a moment later. If something goes wrong in that moment, and the editor is still blank when the first save comes round, that save would write an empty document over the real one. One refresh, and the whole thing would appear to be gone.

The test is deliberately about content, not characters: a document holding only an image or a table is not blank, and it saves normally. Spreadsheets and canvases have the same guard, counted in cells and in elements.

The guard has a cost, and we chose to pay it. If you select everything in a document and delete it, leaving it truly empty, that emptiness is not saved until your next real edit, and the stored copy still holds the old text, so it can reappear when the document is next opened. It is a strange moment, but the alternative is a rule that sometimes deletes a document nobody meant to delete, and between an empty page that returns and a full one that vanishes, the first is the one you can live with.

Between an empty page that comes back and a full one that vanishes, there is only one safe default.

What happens when everybody leaves?

The room does not disappear the moment the last person disconnects. Connections drop and come back all the time, behind a proxy, on a train, when a laptop sleeps for a second, and tearing the room down on every blip would mean rebuilding it from the database on every reconnect. So an empty room waits for 10 seconds first, and its save timers keep running while it waits.

When it does close, it saves before it lets go, and it waits for that save to finish. Until it has, the room stays registered, so somebody who reopens the document in that moment gets the live room with the real content rather than an older copy from the database. If the save keeps failing, the room is not thrown away at all: it keeps the edits in memory and keeps retrying, because a room that gives up quietly is a document that loses its last minutes quietly. A failed save is retried after 1.5 seconds, up to 6 times in a row, and a later edit or reconnect starts the attempts again.

None of this is visible when it works, which is the point. You can read what the editor shows you in Writing a document, find older versions in Version history, see what to do when the chip will not turn to Saved in saving and sync problems, and see the rest of the editor on the Docs page.

What happens after the write is a story of its own. The content is encrypted before it reaches the database, and whether you may change a shared document at all is decided by your role in the workspace, checked on every write.