Rama's programming model is different from how most applications are built. Most applications have an application layer and a database layer, where the database stores the "current state of the world". The application layer does reads and writes to the database.

In architectures like this, the database is both the source of truth for the application as well as an indexed store to serve queries efficiently.

In contrast, Rama's programming model is based on event sourcing and materialized views. In this model, the source of truth is different from the indexed stores. Data gets appended to an unindexed log, and any number of indexed stores, also known as materialized views, are created from that log. Most of Rama programming is defining the logic to process one or more streams of incoming data and incrementally materialize those views.

There are big advantages to separating the source of truth from the indexed stores that serve queries. You're never forced to denormalize your source of truth for performance since the source of truth doesn't serve queries directly, so achieving data consistency is much easier. The log can be used to compute new views in the future, or it can be used to recompute an existing view if you make a mistake. The log also serves as a natural audit trail.

While traditionally event sourcing is only for asynchronous use cases, due to the consumption of a queue system being uncoordinated with a client doing appends, this is not the case with Rama. Because Rama is an integrated system, clients doing appends can optionally coordinate with downstream processing so that an append only returns to the client when all downstream processing and updates to materialized views have completed. This makes Rama suitable for highly interactive use cases as well as asynchronous use cases.

Note that because Rama is an integrated system, the extra step of materializing a durable log does not result in lower performance (as we've shown in benchmarks). Rama is able to sustain as good or better read/write throughputs/latencies as compared to state-of-the-art databases.

Rama applications are programmed entirely with either its Java API or Clojure API. They consist of three components: depots, topologies, and PStates. These are explained in the next sections.

JVM clients to a cluster can use Rama's native Java or Clojure APIs to do appends and reads, and clients of other languages can use Rama's REST API.

Depots and PStates are incrementally replicated, as opposed to the snapshot-based replication many other systems use. This means when there's a failure on the cluster, there is always a replica ready to take over immediately. This makes Rama suitable for any use case databases are currently used.