ClickhouseProblem & solution
How Bullet uses ClickHouse Cloud to give DeFi's fastest exchange real-time analytics
Summary
Bullet operates a DeFi exchange for perpetuals, spot trading, and lending, with trades settled on a blockchain while users retain custody of their assets. Its sub-millisecond trading system produces more than 150 million event rows per hour, creating a need for historical indexing, real-time analytics, and operational monitoring beyond the blockchain’s state-machine model. ClickHouse Cloud consumes events from Kafka, stores them in dedicated tables, and supports user features, leaderboard and reward calculations, P&L charts, audit logs, and Grafana-backed alerts. Replacing Databricks reduced query latency from 10–15 seconds to milliseconds, improved data freshness from 1–2 hours to under 5 seconds, and removed a separate DynamoDB serving layer at comparable cost while handling 1,000 times more data across staging, testnet, and mainnet.
Context
Bullet needed fast, queryable history and live analytics for a blockchain exchange whose state-machine architecture does not retain historical events. Its previous Databricks-based setup produced 10–15-second queries and data that could be 1–2 hours stale, while the team also faced maintenance overhead from a multi-system data stack.
Approach / What changed
A Rust indexer receives exchange events over WebSocket and batches them into Kafka on AWS MSK. Redpanda Connect classifies and routes events to dedicated Kafka topics, with a parallel S3 Glacier feed for disaster recovery. ClickHouse Cloud consumes the topics directly into dedicated tables, supporting user-facing analytics, monitoring snapshots, and refreshable materialized views.
Takeaways
ClickHouse Cloud’s columnar storage and compression suit Bullet’s append-only blockchain workload, which exceeds 150 million rows per hour and previously used uncompressed JSON in S3.
Dedicated ClickHouse tables for event types allow each dataset to be sorted and ordered around its important fields, keeping queries fast while Kafka integration avoids custom ingestion wiring.
Refreshable materialized views reduced leaderboard freshness from as much as 90 minutes in the previous setup to a 10-minute refresh interval, with the option to run every minute.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.