Rama in five minutes (Clojure version)

As an engineer, you want to ship product features. However, backend engineering gets bogged down by everything around those features: adding caches, wiring background workers, adding queues, handling migrations, and coordinating deploys. The actual business logic is usually a small part of the work.

To make this concrete, imagine building a small todo app: users add todos, complete them, view their todo list, and see how many they’ve completed.

This post shows how this is built in a traditional Postgres stack versus Rama. You’ll see how Rama eliminates all the infrastructure sprawl and glue code. If you’re using NoSQL databases or processing frameworks, you would incur the same costs as the Postgres version, just wearing different clothes.

Each has its own scaling and deployment procedures, all for a tiny, medium-scale application. At high scale, a complete rearchitecture would be needed to make everything horizontally scalable, adding even more systems into the mix.

Rama gives you a foundation that eliminates this glue code, infrastructure sprawl, and one-off scripts.

In the Postgres-based stack, you can’t send every write through a queue because processing that queue is asynchronous. Some operations, like adding a todo, must be visible immediately on the next read, not some indeterminate time later. So some writes go directly to the database while others go through a queue. The result is a split system where some paths are synchronous and others are asynchronous.

In Rama, every write goes through a queue called a “depot”. The key difference is that a depot append can support synchronous or asynchronous use cases. When appending you can choose to wait for only the log write to finish, or you can also wait for downstream processing to complete. This makes the depot-first model suitable for both interactive UI paths and background work, and this unified flow is the backbone of Rama’s architecture.

Besides depots, a Rama application (called a “module”) also includes business logic (called “topologies”) and storage (called “PStates”). Rama applications follow this flow: events enter a depot, your logic processes them, and any number of PStates are updated.

Every aspect of Rama is horizontally scalable. “PState” stands for “partitioned state” and is like a database (e.g. durable on disk), but much more flexible.

Explaining Rama’s full API would take more space than this post allows, so we’ll instead explain the implementation in broad strokes. To dive deeper, check out this blog post series which contains line by line tutorials of applying Rama to a wide variety of use cases.

Let’s start by building the “todos + completed_count” features, and the next section will add the ability to reorder lists. You can see the full code for this module here.

One depot is needed:

As opposed to databases which have fixed data models, PStates are defined as any compound data structure.

Next are the event types that will be appended to the depot:

This is ACID-compliant. Deploying, updating, and scaling this module are all one-line CLI commands. Rama replicates all state for fault-tolerance, and it has extensive monitoring of all aspects of module execution viewable through the Rama web UI.

The gap between the traditional approach and Rama only grows with more features or higher scale. As an application grows, traditional stacks accumulate operational work: schema changes, backfills, and deploy choreography. Adding databases or other infrastructure is common. The complexity of both development and operations keeps multiplying.

Rama avoids that complexity and sprawl entirely. Rama applications require little code because they’re almost all business logic, and deployment and scaling are built-in. The same codebase will carry you all the way to large scale, so there’s no hidden rewrite waiting for you when usage grows.

Most importantly, Rama is general purpose. For an example of this, we re-implemented the entirety of Mastodon to be Twitter-scale in only 10k lines of code. The project implements an extremely diverse feature set: timelines, social graph, search, recommendations, trends, scheduled posts, and much more.

Rama also gives you huge flexibility from depots capturing every change. You can replay them later to build new derived views, and you gain a complete audit log for debugging if something goes wrong.

The more your product grows, the more time and money Rama saves. It keeps the backend focused on business logic rather than the scaffolding around it.