A tool for applications to automatically scale their queue resources at runtime based on demand.
Slinqy is a library that simply wraps calls to your existing queuing infrastructure so that it can scale your queuing infrastructure for you, dynamically at runtime and transparently to your application.
If you have a queue-based application that receives a constant influx of traffic and you cannot afford to lose or reject any of it due to a backend failure, then Slinqy may be a good solution for your application.
YourCurrentQueueClient queueClient = QueueClient.CreateFromConnectionString(connectionString, queueName);
await queueClient.Send(message);
message = await queueClient.Receive();
etc...
IPhysicalQueueService physicalQueueService = new YourQueueServiceWrapper(connectionString);
SlinqyQueue queueClient = new SlinqyQueueClient(physicalQueueService).Get(queueName);
await queueClient.Send(message);
message = await queueClient.Receive();
etc...During normal operation, your application will process queue messages in a timely fashion.
Unfortunately, issues can arise that prevent your back end from processing queue messages for prolonged periods of time. Queues, high traffic queues in particular, can become full in such situations. Either requiring frantic manual intervention or worse, reaches full and the upstream users begin receiving errors...
Slinqy will automatically grow the storage capacity of your queue if utilization nears full so that you and your users never encounter queue full errors.
A Slinqy queue is a virtual queue that can be made up of one or more physical queue shards.
Under normal circumstances, Slinqy will only use one queue shard. But if queue storage utilization reaches or exceeds the threshold you configure then Slinqy will automatically add additional queue shards to accommodate, which will be seamless to your application.
Slinqy will always send new messages to the highest physical queue shard and always read from the lowest physical queue shard to maintain the order of your messages.
The core logic of Slinqy is not written against any particular queuing technology. This provides several benefits:
- You won't be waiting on us to integrate the latest and greatest of your particular queuing tools in to Slinqy.
- No waiting or being held to older versions of your queuing tools.
- Can work with any queuing technology.
Slinqy works against a set of interfaces that you implement. Since you provide the queue technology specific implementation, it can be anything!
Slinqy is currently only available in source form from this repository. It will soon be available via NuGet.
IPhysicalQueueService: The interface that allows Slinqy to manage your queuing technology of choice.
IPhysicalQueue: The interface that allows Slinqy to send and receive messages.
Enqueues your messages. At least one instance per queue per application process is required. This is the only component that sends messages to the queue.
Dequeues messages for processing. At least one instance per queue per application process is required. This is the only component that receives messages from the queue.
Periodically pulls the current status of the shards from your queue infrastructure, typically shared by multiple components. One instance per queue per application process is required. This is the only component that polls the state of the physical queues.
Periodically evaluates the shards and performs scaling actions if necessary. One instance per queue per application is required. This is the only autonomous component that manipulates your queue infrastructure.