Keethu delivers messages to 100,000 concurrent subscribers with ≤10ms p99 latency — on a single machine. No Kafka cluster. No distributed overhead. Just physics.
Each published message fans out to all subscribers in ~35 ns per subscriber. At 100K subscribers, the full fan-out completes in ~3.5ms — well inside the 10ms budget.
Topic-to-subscriber mapping lives in a DashMap with 128 independent shards. Publishing to /sports and /finance simultaneously has zero lock contention.
Message payloads are reference-counted Bytes objects. Delivering to 100K subscribers clones a pointer, not data — total bytes copied: zero.
Each subscriber gets its own bounded mpsc channel. Slow consumers are isolated — one lagging client never stalls the fan-out for everyone else.
A 16-byte fixed header + JSON metadata + raw payload. Parse cost: 4 integer reads. No header scanning. No ambiguity. Wire captures show KEET… for instant identification.
Tokio's work-stealing scheduler runs async tasks across all CPU cores. No GC. Deterministic memory. 100K connections on ~10MB of task state instead of 800GB of thread stacks.
16-byte binary header + JSON metadata + raw payload. Keethu decodes the header in <100 ns — four integer reads, no scanning.
A single AtomicU64::fetch_add stamps the message with a global sequence in ~5 ns. No mutex. No coordination.
The topic string hashes to one of 128 shards. Only that shard's lock is acquired for ~20–50 ns. All other topics proceed in parallel.
Cache-friendly Vec iteration. Per subscriber: clone a Bytes pointer (O(1)) + try_send to their mpsc channel (~10 ns). Total: ~35 ns/subscriber.
Each connection's write task reads from its channel and calls write_all. Tokio's epoll reactor fires only when the socket is ready — no polling, no wasted cycles.
Push stock quotes, order book updates, and trade ticks to thousands of trading terminals simultaneously with deterministic latency.
Broadcast position updates to all players in a room at 60 Hz. Each frame must reach every client within one tick — 16ms.
Fan out sensor readings from thousands of devices to dashboards, alerting systems, and data pipelines in real time.
Stream metrics, logs, and analytics to ops teams and monitoring systems. No polling. Push the moment data changes.
Sync document edits, cursor positions, and presence data between users in shared workspaces with sub-millisecond propagation.
Deliver bid updates and countdown events to all participants simultaneously. Fairness requires every subscriber gets the same data at the same time.
Keethu's design is driven by a precise latency budget. Here's where the time goes on a loaded system delivering to 100K subscribers.
| Operation | Cost | Technique |
|---|---|---|
| Frame decode (16-byte header) | < 100 ns | 4 u32 reads, no scanning |
| JSON header parse | 500 ns – 2 µs | serde_json, simd-json option |
| Sequence number stamp | ~5 ns | AtomicU64::fetch_add (Relaxed) |
| DashMap topic lookup | ~20–50 ns | 128-shard hash, single shard lock |
| Delivery frame build per subscriber | ~200 ns | Bytes::clone is O(1) |
| try_send to mpsc per subscriber | ~10–20 ns | Lock-free channel push |
| Fan-out 100K subscribers (serial) | ~3–5 ms | 35 ns × 100K |
| TCP flush via Tokio epoll | ~2–5 µs / conn | Edge-triggered, non-blocking |
| Total p50 end-to-end | ~4–6 ms | LAN, fully loaded |
| Total p99 target | ≤ 10 ms | Includes scheduling jitter |
The deep-dive guide covers CPU cache hierarchies, OS scheduling, TCP internals, Rust's ownership model, and Tokio's work-stealing scheduler — every concept behind Keethu's architecture.
Zero to production-quality Rust in 12 focused hours. Ownership, async, traits, macros, unsafe — every concept with real code. No prior systems experience required.