Skip to content

FAQ

Actionbase is a database for serving user interactions—likes, recent views, follows, reactions.

It models interactions as who did what to which target, and materializes read-optimized structures at write time. Reads use bounded access patterns (GET, SCAN, COUNT).

Actionbase is not a general-purpose graph database. It focuses on serving user interactions with predictable read patterns.

The name reflects what it stores: user actions, modeled as interactions.

What do “interactions” and “activities” mean in Actionbase?

Section titled “What do “interactions” and “activities” mean in Actionbase?”

An interaction captures a user action (like, view, follow) as an explicit who → what → target relationship with schema-defined properties.

Internally, interactions are represented as edges in a graph. The terms “interaction” and “activity” are used interchangeably.

  • Storing and querying recent views
  • Managing likes, reactions, and their counts
  • Handling follow relationships

Instead of reimplementing indexing, ordering, and counting logic per service, Actionbase pre-computes these at write time.

  • A single database instance handles your workload
  • You need general-purpose graph queries or traversals
  • Your team doesn’t have HBase operational experience
  • You’re not hitting scaling walls yet

Actionbase has been running in production at Kakao for years—serving Kakao services, primarily KakaoTalk Gift—handling over a million requests per minute.

However, as an open source project, Actionbase is just getting started. Documentation for production deployment (Kubernetes, HBase operations) is still in progress. Early adopters should expect some rough edges.

Development started at Kakao in 2023. After deployment to KakaoTalk Gift, it was open-sourced in January 2026 — see Path to Open Source.

Actionbase uses a property graph model:

  • Source: who (e.g., user)
  • Target: what (e.g., product, content)
  • Properties: schema-defined attributes (e.g., created_at, reaction_type)

Each interaction type (likes, views, follows) is defined as a separate table with its own schema.

What is the difference between unique-edge and multi-edge?

Section titled “What is the difference between unique-edge and multi-edge?”
  • Unique-edge: One edge per (source, target) pair. Identified by source and target.
  • Multi-edge: Multiple edges per (source, target) pair. Each edge has a unique id.

Unique-edge fits likes, follows, recent views. Multi-edge fits cases like gift records where the same user can send multiple gifts to the same recipient.

Note: Current documentation focuses on unique-edge. Multi-edge documentation will be expanded later.

Does Actionbase support vertices (entity data)?

Section titled “Does Actionbase support vertices (entity data)?”

Currently, Actionbase focuses on edges (interactions). Entity data like user profiles or product information is typically stored elsewhere (e.g., RDB).

Vertex support is planned for future releases. In the meantime, self-edges (source = target) can be used as a workaround for simple entity storage.

Yes. Schemas define:

  • Source and target identifier types (int, long, string, etc.)
  • Interaction properties and their types

Schemas determine which read-optimized structures (indexes, counts) are built at write time — see Schema and Metadata API.

Recent views

  • Source: user_id
  • Target: product_id
  • Properties: created_at

Reactions

  • Source: user_id
  • Target: content_id
  • Properties: created_at, reaction_type

Actionbase processes interactions using a state-based mutation model:

  1. Read current state
  2. Apply incoming interaction as a state transition
  3. Persist resulting state and read-optimized structures

Even if events arrive out of order, the final state remains consistent.

Actionbase pre-computes State, Index, and Count structures when edges are written. This enables simple GET, COUNT, SCAN reads without query-time computation.

  1. State — current relationship between source and target
  2. Index — ordered structures based on properties (e.g., created_at DESC)
  3. Count — counters (e.g., number of likes per item)

Core Concepts.

How does Actionbase handle out-of-order events?

Section titled “How does Actionbase handle out-of-order events?”

Clients attach timestamps to events. Actionbase uses these timestamps to compute the correct final state, regardless of arrival order — see Mutation.

What storage backends does Actionbase support?

Section titled “What storage backends does Actionbase support?”

Storage is abstracted in Actionbase. Any backend that meets the interface requirements can be plugged in. HBase is the current implementation; lighter backends are planned — see Storage Backends.

Tested with HBase 2.4 and 2.5. No strict version requirements.

At Kakao, two storage options met the interface requirements at this scale: HBase and Redicoke (Kakao’s distributed KV store with Redis protocol).

Both provide horizontal scalability, durability, and low-latency random reads/writes. We chose HBase because it was better suited for large data migrations via bulk loading.

Note: Bulk loading is part of the pipeline component. The initial open source release focused on Actionbase core; pipeline release is in progress.

  • WAL (Write-Ahead Log) — records incoming events as-is for replay and recovery
  • CDC (Change Data Capture) — records resulting state after mutation for downstream sync

Both are accessible via Kafka consumers.

How does Actionbase support analytics and pipelines?

Section titled “How does Actionbase support analytics and pipelines?”

WAL and CDC streams can feed analytics systems, async processors, background jobs, or data migrations.

Can Actionbase handle high write throughput?

Section titled “Can Actionbase handle high write throughput?”

For high-frequency interactions (e.g., recent views), Actionbase uses async processing via Spark Streaming:

  1. Request queued to WAL, response returned immediately
  2. Async processor (Spark Streaming) consumes queued WAL entries and sends mutations back to Actionbase
  3. Mutations are throttled and applied in background

This minimizes latency while sustaining throughput. Data is typically reflected within tens of milliseconds. Designed to remain stable even when traffic exceeds normal capacity.

Note: The pipeline component is currently internal. Open source release is in progress.

Actionbase is not a general-purpose graph database.

  • Neo4j — general-purpose graph queries, traversals
  • Actionbase — bounded access patterns (GET, SCAN, COUNT) for user interactions

How does Actionbase compare to traditional RDBMS?

Section titled “How does Actionbase compare to traditional RDBMS?”

Actionbase is not a replacement for RDBMS.

  • RDBMS — general-purpose, transactional
  • Actionbase — specialized for user interactions at scale, with write-time materialization

For most teams, a well-tuned RDBMS handles this fine. Actionbase exists for cases where that stopped being true.

What are typical use cases for Actionbase?

Section titled “What are typical use cases for Actionbase?”
  • Like buttons and reaction counts
  • “Recently viewed” lists
  • Follow/following feeds
  • Per-user interaction histories

When these outgrow your RDBMS—sharding gets painful, caches drift—Actionbase can take over.

Local (development) — see Quick Start

  • Java 17
  • In-memory storage, no external dependencies

Production — documentation in progress, see Roadmap

  • Java 17
  • 4 GB+ memory recommended (scales out horizontally)
  • Requires: HBase, Kafka, JDBC-compatible database for metadata (to be consolidated)

Quick Start.

Yes — documentation in progress, see Roadmap.

Lighter backends are planned for future releases.

Actionbase provides a REST API. Any language that supports HTTP works — see Query API and Mutation API.

Contributing.