architectureevent-sourcingdisruptor-patternlmax

Disruptor Journaling Implementation


In Martin Fowler's write-up of the LMAX-disruptor architecture, he says:

The journaler's job is to store all the events in a durable form, so that they can be replayed should anything go wrong. LMAX does not use a database for this, just the file system. They stream the events onto the disk.

I'm curious what the implementation of the file system based event log looks like in practice. The following answer says that it is written to a "raw file", but I'm interested in the actual details that one might implement for a production system. Is it literally a raw text file containing a structured log that is continuously appended to? Or is it some sort of binary format? Are there any critical design decisions that go into this component of the system?


Solution

  • The journaller as suggested needs to contain two pieces of information: the event itself as received and some sort of an identifier to track where in the journal you are so that you can pick to start from that record during replay.

    Storage format is ultimately your decision, however the following considerations apply: