LavinMQ is an open-source message broker. AMQP 0-9-1, MQTT, HTTP and streaming. Single binary, minimal resource use. If you know RabbitMQ, it's that (but running on a fraction of hardware).
We're the team behind CloudAMQP where we've hosted RabbitMQ for 14 years. Sometimes customers hit issues we couldn't fully explain / work around. So we built our own broker, in order to provide solutions where we previously couldn't (which is much easier when you control the full stack). It all started by me building an open-source AMQP proxy to handle short-lived connections for a customer, to avoid heavy connection churn on cpu. Once the protocol was implemented, adding a persistence layer seemed like a fun challenge. How hard could it be? Turns out the protocol was the easy part. Reliable disk storage, ack handling, and replication was harder. It took years. Our first release was pushed in 2020 and today it runs on 5,000+ production instances on CloudAMQP. LavinMQ is written in Crystal (LLVM-compiled, Go-like concurrency, Ruby-like syntax). Messages go straight to disk via memory-mapped files, no in-memory cache. Append-only writes for both messages and acks. The whole design is built around minimizing memory copies, allocations and syscalls.
Numbers: ~580k msgs/sec on a t4g.micro (2 vCPU, 1 GB RAM). Over 1M msgs/sec on a c8g.large (2 vCPU, 4 GB).
Try it:
docker run -p 15672:15672 -p 5672:5672 cloudamqp/lavinmq
We are curious to hear: how are you handling messaging today? What would make you consider switching broker?
jhk482001•1h ago
abaelter•37m ago
We send the confirm as soon as the message hits the mmap and is appended to the local replication queue because that keeps publish latency at memory-copy speed, and the loss window is narrow: only messages still in the page cache or sitting in the replication queue when the leader dies. Config options are coming to opt into stronger guarantees (msync on the leader, waiting for follower ack, or follower fsync), at the cost of added latency.
yxhuvud•8m ago
jhk482001•8m ago