Comment by em3s | Hacker News Reader

Comment by em3s | Hacker News Reader

Hi HN,

I built Actionbase at Kakao (KakaoTalk, ~50M MAU).

It started because the same features—likes, views, follows—were being rebuilt across teams, each hitting similar scaling walls.

It's been in production for years, serving Kakao services at over 1M requests per minute.

Our approach: precompute everything at write time. Reads are just lookups—no aggregation, predictable latency.

Currently backed by HBase. Lighter backends (e.g., SlateDB) on the roadmap.

Try it — just Docker:

    docker run -it ghcr.io/kakao/actionbase:standalone

Quick Start and production stories are in the README.

Genuinely curious: are there existing systems for high-volume interaction data (likes, follows, views) that I missed?

Happy to answer questions.

Looks a little over engineering, can't just Kafka and any key value db could do the same job with Redis(if required)?

You might be right! Kafka + KV store + Redis can definitely work for this.

Our teams typically started with MySQL, then added Kafka and Redis as they scaled. The pain wasn't the initial build—it was what happened after: every team implemented forward/reverse lists, counts, and indexes slightly differently. Retries and out-of-order events caused subtle drift. Migrations became error-prone because the "rules" for derived data lived in application code scattered across services.

That's what Actionbase does: versioned state transitions, pre-computed indexes, idempotent mutations—all in one place. If your current setup is working and correctness isn't drifting, you probably don't need this.

I wrote more about this trade-off in https://github.com/kakao/actionbase/discussions/32 —genuinely asking whether we overbuilt.

Reply on news.ycombinator.com