Articles
Answers to the question you searched for, with the numbers attached.
Tip1 to 3 min
Note3 to 6 min
Deep dive8 min and up
Problem
All
agent memory
ai agents
ai engineering
at-least-once
batching
buffer pool
bullmq
bytes per row
career
cdn
claude code
claude.md
clickhouse
clickhouse codecs
code review
column ttl
compression ratio
configuration drift
connection pool
context files
cost engineering
data reconciliation
data validation
deduplication
digital signage
digitalocean
disk budget
documentation
doubledelta
durability
edge buffering
eventual consistency
fleet management
guardrails
hiring
idempotency
innodb
interviews
kafka
kafka consumer
leadership
legacy systems
librdkafka
load data
migration
mqtt
mysql
n+1 queries
node-postgres
observability
operations
part_log
performance tuning
php
php-rdkafka
postgres
precomputed snapshot
proof of play
refactoring
reliability
replacingmergetree
replication
reporting
rollout
sharding
sort key
t64
telemetry
timeouts
verification
webhooks
-
Note
1.8 million messages, 200 million rows: checking Kafka against ClickHouse
Our players send one Kafka message per upload, about 112 rows each. How I counted a day of messages from offsets alone, compared them with the rows ClickHouse really inserted, and got 13,912,374 against 13,912,522.
measured ▸ 13,912,374 messages vs 13,912,522 rows in 24 h (0.001%) · 1,782,599 messages carrying ~199.3M rows
-
Note
Moving 14,000 screens to MQTT without losing one
Device presence and telemetry moved from HTTP to MQTT on a fleet of about 14,000 screens. A year-long project, four months of tests and a slow rollout, because the worst case was losing contact with screens in the field. Telemetry messages dropped 67%.
measured ▸ telemetry on Kafka: ~42M messages/day before, 13.9M after (−67%) · 13,835 screens reporting