Predictable hot path
Local messages flow through pre-allocated shared-memory ring buffers, keeping syscalls and heap allocation away from the fast path.
Shared-memory IPC · TCP broker routing · Zig core
Low-latency messaging for clustered services.
RingLoom is a broker and service runtime for predictable service-to-service communication. Same-host services use memory-mapped ring buffers, while brokers route cross-host traffic over framed TCP.
Services
IPC rings
Broker
Control · Send · Receive
Peer brokers
Framed TCP
Why RingLoom
One messaging model for local and remote services.
RingLoom gives services a predictable path for same-host IPC and cross-host routing without introducing a general-purpose queue into the hot path.
Brokered cluster routing
Messages are routed by node and service identifiers, with broker event loops dedicated to control, sending, and receiving.
Operational visibility
Metadata files expose heartbeat state, ring positions, counters, and error logs for tools such as ringloom-stat and the Prometheus exporter.
Documentation map
Build, run, inspect, and extend RingLoom.
Start with the user guides, drill into the runtime stack, or follow community updates as the project evolves.
Get started
Run a broker and send your first messages.
Build the repository, start a broker with a small properties file, then use the included ping and echo services to validate same-host shared-memory IPC.
Build
zig build test verifies the core modules, while zig build install and zig build test-bins install the broker and sample service binaries.
Start
Run ringloom-broker --config broker.properties to create broker metadata and begin accepting service registrations.
Inspect
Use ringloom-stat --storage-path /dev/shm --group ringloom to inspect live rings, counters, heartbeat ages, and metadata state.