Core Concepts

Actionbase is an OLTP engine specialized for user interactions, optimized for high-throughput, low-latency workloads. It uses graph-based modeling specifically designed for user interactions, not as a general-purpose graph database.

User Interactions

Actionbase handles various types of user interactions:

• Recent views (products, content)
• Likes and reactions (hearts, care, emojis, etc.)
• Follows and relationships

These activities share common characteristics: they represent relationships between users and entities, require real-time access, and are queried in predictable patterns.

Property Graph Model

Actionbase represents user interactions using a Property Graph model:

• Source (actor): User ID or any entity that performs an action
• Target: Product, content, user ID, or any entity that receives an action
• Properties: Schema-defined attributes like timestamp, type, metadata, etc.

This model naturally fits user interactions and enables rich query patterns based on properties.

User (source)
  └─ id: "user123"

User --[likes]--> Product (edge)
  ├─ source: "user123"
  ├─ target: "product456"
  └─ properties: {
      timestamp: 1234567890,
      type: "heart",
      device: "mobile",
      location: "US"
    }

User --[follows]--> User (edge)
  ├─ source: "user123"
  ├─ target: "user789"
  └─ properties: {
      timestamp: 1234567891,
      notification_enabled: true
    }

For how to define schemas for your graph, see Schema.

State and Event Model

Internally, Actionbase uses a State and Event model to ensure consistency:

• State: The current state of the state machine (e.g., “user liked product”)
• Event: Input that transitions the state (e.g., “user clicked like button”)

When a user action occurs, Actionbase:

1. Reads the current state
2. Performs a state transition based on the incoming event
3. Stores the new state

The system is designed so that even if events arrive out of order, the final state remains consistent. Clients attach timestamps to events, and Actionbase uses these timestamps to compute the correct final state regardless of arrival order.

For detailed information on how mutations work, see Mutation.

Write-Time Optimization

Actionbase’s key strength is pre-computing data structures at write time for fast, predictable reads. When an edge is written, Actionbase creates three types of pre-computed data:

1. State: Direct records representing connections between source and target nodes
2. Index: Pre-computed indexes based on schema-defined properties (e.g., created_at DESC)
3. Count: Pre-computed counters (e.g., “number of products viewed by user”)

By pre-computing these structures during writes, reads can use simple GET/SCAN/COUNT operations for ultra-fast responses without expensive query-time computations.

For details on how these structures are created, see Mutation. For how queries access them, see Query.

Data Flow

Write Path

Client → Server → Engine → WAL → Storage → CDC

The write path involves:

1. Writing to WAL (Write-Ahead Log) for durability
2. Acquiring locks for consistency
3. Reading current state
4. Applying state transition
5. Computing indexes and counters
6. Writing to storage
7. Emitting CDC for downstream systems

For detailed write flow, see Mutation.

Read Path

Client → Server → Engine → Storage → Response

The read path retrieves pre-computed data structures:

• Count Query → EdgeCounter
• Get Query → EdgeState
• Scan Query → EdgeIndex

For detailed read flow, see Query.

Next Steps

• Schema: Define the structure of your edges
• Mutation: Understand how writes work
• Query: Learn how to query your data
• Datastore: Explore datastore backend options