Show HN: Actionbase – A database for likes, views, follows at 1M+ req/min

[em3s]

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.

[kocialnews]

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

[nubskr]

Won't something like scyllaDB be a better choice for such workloads ? as long as you're fine with eventual consistency ofc

[em3s]

You might be right! ScyllaDB is a solid choice—eventual consistency is often fine for interactions.

The friction we hit was less about storage and more about fragmentation: teams kept rebuilding the same features (likes, views, follows) with slightly different implementations. Counters drifted, toggle logic varied, indexes duplicated.

If you have one team and one use case, ScyllaDB could work well. Our problem was multiple teams hitting the same walls repeatedly.

That said, HBase is just the storage backend—Actionbase is the interaction layer on top. We'd consider ScyllaDB as a backend too. Currently HBase is battle-tested in production, while SlateDB would need dev effort. We'd love community input on direction: https://github.com/kakao/actionbase/discussions/144