tinymq
A channel-based, in-memory message queue for Erlang with automatic channel lifecycle management.
What is tinymq?
TinyMQ is an in-memory message queue for Erlang that organizes messages into dynamically managed channels. It allows processes to push, poll, and subscribe to messages in real-time, with automatic cleanup of old messages and inactive channels. It solves the need for lightweight, transient message passing within Erlang applications without the overhead of persistent storage.
Erlang developers building applications that require simple, in-memory message passing for real-time communication, such as chat systems, event-driven architectures, or intra-process signaling.
Developers choose TinyMQ for its minimalistic design, automatic channel management, and straightforward API, which reduces boilerplate and complexity compared to setting up heavier message brokers. Its in-memory nature ensures low latency, making it ideal for scenarios where persistence is not required.
Overview
TinyMQ - a diminutive, in-memory message queue
Use Cases
Best For
- Building real-time notification systems within Erlang applications
- Implementing lightweight pub/sub patterns for transient data
- Handling intra-application event signaling without external dependencies
- Prototyping message-driven architectures quickly
- Managing dynamic communication channels that come and go frequently
- Creating chat or messaging features in Erlang-based web apps
Not Ideal For
- Systems requiring persistent message storage across restarts or crashes
- Distributed Erlang applications that need message queues spanning multiple nodes
- Use cases where long-lived, continuous subscriptions are needed without manual re-subscription
Pros & Cons
Pros
Channels are dynamically created and destroyed based on activity, eliminating manual lifecycle management and reducing boilerplate code.
The timestamp-based poll API ensures no duplicate messages and guarantees delivery of all new messages, providing a reliable way to fetch data.
Processes can subscribe to channels for immediate message delivery, with subscriptions automatically cleaned up after first delivery to simplify client logic.
Messages are stored in a priority queue optimized for fast access, offering low latency and overhead for transient communication.
Cons
All messages are lost on application restart since it's purely in-memory, making it unsuitable for critical data that must survive failures.
Channels currently reside only on the node where TinyMQ is started, so it doesn't support distributed queuing across an Erlang cluster without modifications.
Subscribers are removed after first message delivery, requiring manual re-subscription with updated timestamps, which adds complexity for persistent listeners.
Frequently Asked Questions
Found a gem we're missing?
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.