Technical Overview

This document is intended to provides a technical overview of Axiom.

Axiom consists of three tiers, which are a slightly modified version of the traditional three-tier architecture.

The traditional three-tier architecture has data, logic and presentation tiers. In Axiom we "upgrade" the data tier to an information tier and "downgrade" the logic tier to a mere gateway tier.

The three tiers communicate by passing events from one to the other. We will therefore start our discussion by describing Axiom's event-sourcing approach.

Event Sourcing

Event sourcing is a common design pattern in applications. An event-sourcing system will typically not store state, but rather store changes to state, in the form of events. When state is required, it can be obtained by "playing" stored events. State can also be cached as an optimization, but only as such. Events are the "single source of truth" in such a system.

Usually, when system architects choose event-sourcing as a pattern for maintaining state in their application, they do so decrease latencies and increase availability in a highly-distributed system.

Maintaining state the traditional way is bound to the limitations of the CAP Theorem. Event sourcing allows us to create events for updating the state without knowing the absolute state at the time of the update. All that is required for such mechanism to work is a consistent algorithm for constructing state based on "played" events, such that no matter what events we got and in which order, the same collection of events will always lead to the same state.

Axiom is a distributed system, so designing it as an event-sourcing system makes sense. However, in Axiom, the need for event sourcing is more profound than in most system, as we will explain next.

Axiom Events

As an event-sourcing system, all communications between Axiom's different components is done through events. Events are also the payload stored in Axiom's database.

Almost all the events used by Axiom follow the same structure. They are Clojure maps containing the following keys:

• :kind: Either :fact, if this event represent a change to a fact, or :rule if it represents a change to a rule. Other values are also possible for special control events.
• :name: A string representing the name of the stream this event belongs to. See fact-table for details.
• :key: The key of the fact or the rule. See here for more details.
• :ts: For facts, the time (in milliseconds since EPOCH) in which this event was created. For rules this is a unique ID constructed from the :ts values of the facts that contributed to this rule.
• :data: The data tuple representing a fact, or the state of a rule, excluding the key.
• :change: A number representing the change. Typically, 1 represents addition, and -1 represents removal.
• :writers: The event's writer-set, represented as an interset.
• :readers: The event's reader-set, represented as an interset.
• :removed (optional): If exists, account for an additional event that is identical to the original one, but with :data = :removed, and :change = -:change.

In the phylosiphical sense, events represent axioms, which the facts and rules they reference represent statements. This distinction is a key component behind Axiom's design -- so important that Axiom received its name from this.

Consider a fact like:

[:weather [:new-york [:date 3 :sep 2017]] :rain 18 23]

depicting the weather forcast for New-York on September the 3rd 2017.

Is this fact an axiom? Can we take it as true? The answer is no. This was the forecast provided by one website on September the 2nd -- one day before. We can, however, take this fact as a statement made by the website on that particular day and time.

However, if this fact came to our knowledge through an event, some of the event's paramters can provide us with context that allows us to better refer to this information. For example, the :writers set will tell us that this fact came from that website. The :ts parameter will tell us when this forecast was stated. The :change parameter will tell us whether the website stated this forecast at that time (a value of 1), or retracted it (-1).

If we properly check the contents of these fields before allowing them in our system (e.g., check that this fact was indeed stated by the website and not by an imposter), we can treat the event as an axiom -- this is indeed what the website claimed the weather was going to be.

This distinction between statements and axioms is a key component in how Axiom works, and in particular, in how it manages access control.