Most applications today are built around two fundamentally different code paths: a synchronous path that writes directly to a database, and an asynchronous path that runs through a queue to background workers or a stream-processing framework.

This split exists because a queue is not coordinated with downstream processing. Writes placed on a queue become visible at an unpredictable time in the future. Many operations, such as anything a user must see immediately on the next page load, must therefore write straight to the database.

A second driver of complexity is databases exposing only a small set of fixed data models. When an application needs a data model the primary database does not support well, such as graph, time-series, or search, teams add another specialized store. Over time, both the split execution paths and the accumulation of different data models compound into significant infrastructure sprawl.

Rama's programming model addresses both these sources of complexity. First, Rama eliminates the split by unifying synchronous and asynchronous work into a single flow.

Every write in Rama goes through a durable log called a "depot". Unlike a traditional queue, a depot append can choose to wait for downstream processing to complete. This coordination is possible because Rama is a fully integrated system: the queue, the processing, and indexed storage all operate under one runtime. That unification means interactive UI writes and background processing share the same mechanism rather than being separate systems with divergent semantics.

Once you have a unified write path, the rest of Rama's model follows naturally:

• A depot is the source of truth, storing the full history as an append-only log.
• PStates ("partitioned states") are the indexed stores built from that log, and they can take any shape rather than being limited to a fixed data model.
• Topologies define how incoming data is processed to maintain those views.

Because Rama integrates the log, processing, and storage into one system, this model does not sacrifice performance. Benchmarks show that Rama matches or exceeds state-of-the-art databases in read/write throughput and latency despite the additional durability guarantees of a log.

Rama's depot-first model also provides huge flexibility. Depots can be used to compute new views in the future, or they can be used to recompute an existing view if you make a mistake. They also serve as a complete audit log for debugging if something goes wrong.

Rama applications are written entirely using its Java or Clojure APIs. They consist of three building blocks: depots, topologies, and PStates.

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.