Consistency, Guarantees, and Uptime

This document covers some low level details about how Lamdera stores your backend data. This is intended for people who are storing business critical data and want to know what data consistency and availability guarantees Lamdera provides.

How backend persistence works in Lamdera

Lamdera apps provide persistence by combining a few architectural properties:

• Write-ahead-log (WAL)
  • Every message is persisted to an ACID data store (Postgres) before it gets processed.
• The Elm Architecture (TEA)
  • Immutable: every event takes the current backend state and returns a new modified copy that replaces the old backend state.
  • Pure & referentially transparent: re-applying the same backend model + message always gives the same result, and cannot read from or act on the world outside those two pieces of information.
  • Sequential & Isolated: Messages are handled one-by-one in order and cannot interfere with each other or mutate state.

This combination allows us to have:

• Persistence: because the backend state is entirely derived from messages, persisted messages mean a persisted backend state.
• Point-in-time recovery: replaying up to a specific message means recovering the backend state as at that point in time, meaning Lamdera apps retain history of every single backend state transition.
• In-memory: The prior two points mean the backend state can live entirely in memory, without worrying about persistence or serialisation, leading to
  • The highest possible performance on retrieval and insertion in application code: nominally 1-2 orders of magnitude faster than an external data store
  • Drastically reduced code complexity within applications:
    • No connectivity or pooling code
    • No separate schema & migration management & synchronisation
    • No data serialisation and disparate type mapping in/out of SQL queries

As a result Lamdera apps demonstrate as low as microsecond latency on Message handling.