Client-Side Event Sourcing
Achieving local-first software's goals by replaying an immutable log of events on the client, rather than syncing a mutable, auto-merging CRDT object — a structurally different but equally legitimate architecture, appropriate when an application's core need is an auditable history rather than freeform collaborative editing.
Also known as: event sourcing (client-side), immutable event log, replay events, three-tier web stack (moving away from)
Part of: Local-First Software
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing Johannes Schickling · 2026-07-27 | Client-side event sourcing | Treating the client's source of truth as an append-only, ordered log of events (not a mutable object), which is replayed to derive materialized state (e.g. a reactive local SQLite database); lets application logic evolve and be reapplied to full history rather than mutating state in place. |
Documents (1)
- Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing Johannes Schickling · 2026-07-27 source ↗ Reader 🖥️
Client-side event sourcing — replaying an immutable log of events rather than syncing a mutable, auto-merging CRDT object — is a structurally different but equally legitimate way to achieve local-first software's goals, and should be adopted (like local-first itself) only when an application's core value genuinely depends on offline resilience, client-side speed, and user data ownership, since restructuring where and how data lives is one of the most fundamental and hardest-to-reverse decisions a team can make.
Propositions touching this concept (1)
By publication month, oldest first (extraction month when no publication date is known).
2026-07
- explicitClient-side event sourcing — an append-only log of events replayed to derive state — is a viable alternative to CRDTs for achieving local-first's goals, trading a different set of complexities for a different set of guarantees.
Open gaps (2)
- incompleteSchickling advocates client-side event sourcing as a general alternative to CRDTs for local-first, but never explains how event sourcing handles concurrent conflicting writes from multiple simultaneous devices or users — the central problem CRDTs were explicitly designed to solve. LiveStore's actual conflict-resolution model for genuinely concurrent multi-writer scenarios is left unaddressed; every concrete example he gives (Overtone) is single-user.Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — read next: LiveStore's own documentation/RFCs on multi-client concurrent writes and conflict resolution; Martin Kleppmann's 'Turning the Database Inside Out' talk, which Schickling names as event sourcing's intellectual ancestor.
- uninformedSchickling states LiveStore is 'still not fully production-ready' but never specifies which production gaps remain (performance at scale, missing tooling, security review, etc.), leaving open exactly how close it is to a safe choice for teams evaluating it today.Podcast: Rethinking Data: Moving From the Traditional Three-Tier Web Stack to Client-Side Event Sourcing — read next: LiveStore's public roadmap/issue tracker for current production-readiness status.