# Event sourcing journal layer

**URL:** <https://forums.foundationdb.org/t/event-sourcing-journal-layer/667>\
**Category:** FoundationDB Layers\
**Created:** [August 27, 2018, 10:53am UTC](https://forums.foundationdb.org/t/event-sourcing-journal-layer/667 "2018-08-27T10:53:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![meln1k](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/meln1k/32/150_2.png) [@meln1k](https://forums.foundationdb.org/u/meln1k)\
**Post date:** [August 27, 2018, 10:53am UTC](https://forums.foundationdb.org/t/event-sourcing-journal-layer/667/1 "2018-08-27T10:53:28Z")

</div>

Hi folks,

I’ve implemented an event sourcing journal for [akka-persistence](https://doc.akka.io/docs/akka/current/persistence.html) using FoundationDB:

> **[meln1k/akka-persistence-foundationdb](https://github.com/meln1k/akka-persistence-foundationdb)**
>
> A replicated Akka Persistence journal backed by FoundationDB - meln1k/akka-persistence-foundationdb

Some features which were possible due to FoundationDB:

- Database push for live queries, it allows ~30ms lag between persisting the event and its appearance in read query stream.

- Safe event insertion mode, if it’s enabled, event writes calls will return an exception if two writers will write an event with the same `persistenceId` and `sequenceNr` . It should prevent the journal corruption in case of split brains.

- Two ways to build secondary event index: a reference to an existing event or a whole copy of the existing event. It helps if you want to be flexible between the amount of used storage space and performance of your reads.