ReckonDB in Action

The best demo is the one you are already looking at. This site runs on ReckonDB, and the worked examples below use the same product you would ship.

Live: the blog on this site is event-sourced on an embedded ReckonDB store. No posts table.

This Blog

Live • Event Sourcing • CQRS

The blog you can open right now is event-sourced. Publishing a post files an event; a projection updates the read model; the page you see is a query against that read model. There is no posts table, the event log is the source of truth.

The path of one post

  • • CMD: publish_post files post_published
  • • PRJ: the projection folds it into the read model
  • • QRY: the page reads the read model, no joins

Worked Examples

Copy-paste • Any language

A bank account that never overdraws, unique account numbers across every stream, a counter and a TODO list. Each one runs over the gateway in plain HTTP/JSON, so it works from any language, not just the BEAM.

What they cover

  • • Appending and reading events
  • • Optimistic concurrency and retries
  • • Cross-stream invariants with DCB
  • • Building a read model

Build Your Own

BEAM-native or polyglot

On Erlang or Elixir, model your domain with evoq aggregates, projections, and decisions over the reckon-evoq adapter. From any other language, drive the same store through the gateway. Start with a single slice and grow.

Where to start

  • • Install the gateway or add the hex packages
  • • Append your first events
  • • Enforce an invariant with a DCB
  • • Project a read model and query it

What You Are Seeing

Event Sourcing

Every change is stored as an immutable, past-tense event, a complete audit trail you can replay.

Rebuildable Read Models

Projections fold events into query-shaped read models that can be thrown away and rebuilt from the log.

CQRS Departments

The write side (CMD) and the read side (PRJ, QRY) are separate, so each scales and changes on its own.

Ready to Build Your Own?

Start building event-sourced applications with ReckonDB today.