“Nothing failed. The document simply became a different document.”
What was created is not what is valid
Three systems, three domains, one decision: separate the moment something exists from the moment it counts.
A customs authority needed invoices that could never change after issue. A remittance terminal needed to print a coupon while offline without risking a double payout. A meeting platform needed a whiteboard that survived the meeting as something you could still work with.
Three unrelated products, three unrelated years — and the same answer each time. What a system stores must distinguish between “this exists” and “this is binding”.
The problem
The constraint
What we did
Customs invoicing: frozen at the moment of issue
The requirement was absolute: an issued invoice must never change. So at the moment of issue the document is rendered and stored as immutable HTML. Later template edits touch nothing already issued.
Issued is issuedThe definition of a document, separated from the issued document
The template is free to evolve; history stays intact. A second benefit is easy to miss — the frozen output no longer depends on the future correctness of the rendering code. Had documents been rendered on demand, any change to that code would have retroactively altered every old document.
Independent of future codeThe coupon prints — and is not valid
A recipient collects cash at a filling station using a coupon code. The terminal has to keep working when the network doesn’t, but a coupon that pays out twice is the one failure that costs real money. So it becomes valid when the system says so: automatically when connectivity returns, or manually through an operator, who is signalled that an unactivated coupon exists.
Better unusable than paid twiceThe whiteboard as objects, not as an image
The board is persisted as structured objects rather than a flat image — every stroke, shape and piece of text keeps its own properties. It can be reloaded and edited rather than only viewed.
Survives the closed session
The issued document is rendered and stored as immutable HTML. Later template edits touch nothing issued — and the frozen output does not depend on the future correctness of the rendering code.
The result
What we’d do differently
On the customs system, freezing the issued document was correct but incomplete: we never versioned the template itself. So while no issued invoice could change, there was no record of which template version produced it, or who changed it and when. The snapshot answered the urgent question and left the audit question open.
- Node.js
- PostgreSQL
- Kotlin
- Fabric.js