Orthogonal Persistence:
the Model
the Model
François-René Rideau
<fare@mukn.com>LambdaConf 2025-05-12
PgDn: next | PgUp: previous | ↑ ↓ ← → ESC ⏎
| Touchscreen: swipe down until you must swipe right |
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Prelude: Orthogonal Persistence?
A Simple Story (1)
   |
Prelude: Orthogonal Persistence?
A Simple Story (2)
   |
Prelude: Orthogonal Persistence?
Persistence vs What?
Persistence is when your data survives
BUT! Failure model: what does it survive?
Unexpected: power loss, accident, hack, theft, fire, war
Expected: hardware and software end-of-life
Prelude: Orthogonal Persistence?
Old Tech Made New Again
OODB 1980s-now: Lisp, Smalltalk, C++, Java...
1980s-1990s: EUMEL, EROS… Funding dried 2000s-2010s.
Today “Durable Execution”. Renewed research.
Me: From my good old HP28 to ORMs to StrongBOX
Prelude: Orthogonal Persistence?
Thesis
Orthogonal Persistence (OP) is the Right Thing™
Persisting Continuations simplifies everything else
Transactions are the wrong abstraction
OP completely solves many problems, elevates the rest
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Today: Fractal Transience
Disappointing Users
My mom's book database
C-x C-s in my fingers
Who never lost data to no/bad/lost backups?
... Don't modern Apps autopersist data?
Today: Fractal Transience
Vendor Lock-In Persistence
Only easy case: won't sync across devices, accounts...
Forced Code Upgrade or Lack Thereof
Product Cancellation, Change of Ownership, Bankruptcy
Data Hostage: pay bills & pray Vendor healthy
Today: Fractal Transience
Developers: Hard Mode
Computers, processes, etc., start empty
Explicitly save and restore all data
Storage Zoo: FS, DB, Web, git...
Fake it the hard way, and Admin the mess
Today: Fractal Transience
Hard Problems
Managing Many Out-of-Sync Copies
Fragile Backups
Schema Upgrades
Merging Data
Today: Fractal Transience
What If...?
Persistence was the default
No more vendor lock-in
Developers don't have to care... except specialists
Hard problems are made easier somehow?
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Orthogonal Persistence for Users
It’s Just There
Data “just” persists
Code runs in ambient “domain”
Interactions, e.g. Editing Documents, not “Apps”
Backup Storage Provider Subscription
Orthogonal Persistence for Users
Example Domains
(me (work (client1 client2 client3 hr))
(home (taxes kids cooking))
(secret (cia kgb mosad))
(love (wife lover1 lover2)))Orthogonal Persistence for Users
Domains
User creates sub-domains
Origin Domain Validates Copy Out / Share Out
Destination Domain Validates Paste In / Share In
Resource Accounting, Storage Providers
Orthogonal Persistence for Users
Document
Edit, Interact at will
Always Saved
Not always publishable
Share some versions with some people, one way or both
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Orthogonal Persistence for Developers
Just Do It
Variables and Processes “just” persist, can be shared
No more save and restore, copy and send
Eliminate 30%-70% of all code — just for variables
Processes may no longer fail mid-invariant
Orthogonal Persistence for Developers
Capabilities: Photo App
Photo App: save... over net... download extensions
Regular App: will compromise your entire computer
Persistent App: can only edit given picture
Wider Reflective Capability Architecture
Orthogonal Persistence for Developers
Security Improvement
Fewer things to think about
Fewer things to get wrong
Smaller attack surface
Whoever reaches for forbidden capabilities is hostile
Orthogonal Persistence for Developers
Full Abstraction
Strong Separation of concerns
App developer not allowed to see how data is persisted
Persistence Implementer not allowed to see data
User or Admin can configure service and providers
Orthogonal Persistence for Developers
Storage Providers
All data encrypted with use-once salt
Add/Remove Provider... independent worldwide replicas
Management layer handles RAID replication
Financial layer plans (un)subscriptions
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Programming Model for Orthogonal Persistence
Manual Persistence Sucks
PL: Everything Transient—but via complex storage protocols
DB: Everything a Table—but Queues, Procedures...
Everyone: Processes are inherently transient
No eff* way to persist continuations or dynamic code
Programming Model for Orthogonal Persistence
Transactions are Bad
Require Global Knowledge
Don't Compose
Always too small or too big
Low Level Concept, no one wants to use
... Necessary because processes don't persist
Programming Model for Orthogonal Persistence
Anti-Transactions are Good
“Don't transact here”, a.k.a. Critical Section
Section itself small, code that uses it large
Local Knowledge Only, Composable
High-Level Concept, already used everywhere
... Possible because processes do persist
Programming Model for Orthogonal Persistence
Don’t Commit, Synchronize
Local constraint, automatically fulfilled
Always persist private data before to publish transaction
Just like memory barriers in modern processors
High-Level Concept, already used everywhere
Programming Model for Orthogonal Persistence
Databases are Bad
Package deal persistence w/ data & execution model
Database come with really bad PL
Databases themselves don't persist
Databases don't (de)compose
Programming Model for Orthogonal Persistence
Domains are Good
Works with your data model, execution model, PL
Identity not tied to a disk, machine, vendor, etc.
Dynamically add or remove backends
Dynamically join (sub)Domains in consensus
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Decoupling Issues from Persistence
Never Save and Copy, Publish and Share
Never Save, Tag Stable Versions
Never Copy and Modify, Fork Versions
Never Copy and Send, Publish and Share
Never Forget, Cache and Remember
Decoupling Issues from Persistence
Never get OOM, manage quotas
Stop processes & escape to metasystem
Adjust and Restart: increase quota, GC, fix bug…
Meta: Predict usage, anticipate increase
Remember correlation of live code and data
Decoupling Issues from Persistence
Never Migrate, Upgrade and Reconfigure
All Schema, Backends will eventually get obsolete
Schema Upgrade support in PL, testing
Reconfigure backends, no lock-in to hw, sw, vendor
Normal operations, not million-dollar crises
Decoupling Issues from Persistence
Never Corrupt, Maintain
No Corruption-prone yet Static language
Low-level or transient code in isolated VMs within Domain
Live systems to cultivate, not dead programs to throw away
Debug using reflection within version forks
Orthogonal Persistence, the Model
Plan of the Talk
- Prelude: Orthogonal Persistence?
- Today: Fractal Transience
- Orthogonal Persistence for Users
- Orthogonal Persistence for Developers
- Programming Model for Orthogonal Persistence
- Decoupling Issues from Persistence
- Conclusion: Consequences of Orthogonal Persistence
Conclusion: Consequences of Orthogonal Persistence
Thesis (Recap)
Orthogonal Persistence (OP) is the Right Thing™
Persisting Continuations simplifies everything else
Transactions are the wrong abstraction
OP completely solves many problems, elevates the rest
Conclusion: Consequences of Orthogonal Persistence
Different Software Architecture
Reflection, Capabilities, Versioning, Upgrade, Consensus…
Pervasive changes throughout all system
Change mindset from PL to System Paradigm
Run legacy code in managed VMs
Conclusion: Consequences of Orthogonal Persistence
Economic Implications: New Markets
Documents and Modules, not Apps
Local Code, not Spying Advertising App Servers
Competing Blind Storage, not Vertical Monopolies
Admins answer to Users, not to App Vendors
Conclusion: Consequences of Orthogonal Persistence
Social Implications: Better Division of Labor
Users: Empowered, Refocused—Can Delegate Admin
Developers: Less Repetition, More Specialization
Providers: Breaking Vertical Monopolies
Defenders: Better Control on Smaller Attack Surfaces
Conclusion: Consequences of Orthogonal Persistence
Orthogonal Persistence's Time Has Come!
Whoever makes it usable first will redefine the industry
Fund me — or be hired by me!
<fare@mukn.com>