llingr.io provides an Apache Kafka consumer engine that delivers high concurrency and massive scaling headroom without requiring additional partitions. The ll ingr-demux engine uses hardware-sympathetic design and a zero-allocation hot path to achieve near-linear scaling, sustaining over 100,000 messages per second from a single partition. It integrates with existing broker client configurations through a port-binding builder, requiring only two callback functions.
Funding
Funding not disclosed
Founders
Product
Problem
Conventional Kafka scaling requires over-provisioning partitions, which leads to larger, more costly broker clusters and hidden operational expenses. Repartitioning introduces availability, latency, and ordering risks, while capacity planning and multi-team coordination become ongoing overhead. There is no Kafka API to remove partitions, making this scaling approach permanent and expensive.
Solution
llingr.io provides the ll ingr-demux engine, a Go-based Apache Kafka consumer engine that delivers concurrency and massive scaling headroom without partition sprawl. The engine is micro-engineered with hardware-sympathetic design, including cache-line field ordering, false sharing mitigation, and lock striping, to make concurrency coordination effectively invisible next to business logic and networking latencies. It uses a zero-allocation hot path where all messages are carried through the pipeline in a WorkItem borrowed from a Go sync.Pool, achieving at most one allocation per message. The engine provides concurrency automatically, requiring developers to implement only two synchronous callbacks—ProcessMessage and WriteDeadLetter—while it handles concurrency, offset management, and lifecycle coordination. Benchmarks show near-linear scaling to approximately 750x concurrency per consumer instance, with framework overhead of only ~1.26µs on consumer-grade hardware. A single consumer reading from one Kafka partition sustains over 100,000 messages per second at ~2% CPU utilization.
Target Audience
Primary users are Go developers building event-driven systems on Apache Kafka who need high throughput and concurrency without partition sprawl, as well as engineering teams at companies running Kafka clusters who want to reduce infrastructure costs and eliminate capacity planning projects.
Features
- Zero-allocation hot path: all messages reuse a single pre-allocated WorkItem from a Go sync.Pool, with at most 1 allocation per message and zero-allocation offset committing
- Hardware-sympathetic design: cache-line field ordering, false sharing mitigation, store buffer locality, branch prediction optimization, and instruction cache locality compound to reduce execution path length
- FNV-1a hash routing with bitwise shard selection: shard count is always a power of 2, using a bitwise AND mask instead of integer division for 1-2 cycle hash-to-shard mapping
- Lock striping with independently locked worker shards: amortizes mutex contention across a pool of worker pools while maintaining correct message ordering
- Batched commit ingest: mutex acquired once per batch of up to 1000 messages rather than per message, with offset resolution inside the same lock hold
- Cold/hot worker parking: idle workers block on channel receive at zero CPU, transitioning to a non-blocking drain of queued messages when the first message arrives
- Port-binding builder pattern: adapters work with existing broker client configurations (franz-go, confluent-kafka-go) without modification, requiring only two callbacks
- Configurable concurrency: ConcurrentKeys parameter adjustable from 250 (default) to 5,000, with 13 tuning parameters for pipeline optimization
- Metrics integration: Prometheus, Datadog, and CloudWatch sinks available, with partition keys deliberately excluded to prevent sensitive data disclosure
- gRPC relay sidecar for non-Go languages, with Java adapter (Jul 2026), C# (Sep 2026), and FFI bindings for Python, Rust, and C/C++ planned