Knowledge of what a queue is and what queue data structures actually do in various computing applications is important when selecting a queue, but those are not the only factors to consider when determining which queue is right for your application. As is the case with any element of the IT budget, understanding the cost drivers associated with your queuing service is critical to reducing overall spending while maintaining innovation velocity.
In part three of this blog series, we’re going to talk about queue pricing, different queue cost drivers and why understanding a queuing service’s cost and its impact is vital in the competition for your organization’s likely limited IT resources.
Contents
Queue Pricing Cost Drivers
The performance of the queue service you select will not be linear. Consequently, when it comes to queuing optimization, the goal is to minimize both the cost of waiting and of service, finding the right balance between the supply of services and the consumer demand on the system or application side. While many popular queue solutions allow you to only pay for what you use, several factors can impact queue pricing.
Queue Durability and Pricing
Quite often, data needs to remain safe in the event of transient failures. When an organization is intolerant to loss of data or can’t reconstruct the state easily, it’s important to use a durable and highly available queue.
Using memory as an example, if your computer loses power, everything in your queue is lost — and there’s no guarantee of retention or delivery. With cloud-scale services, systems or applications, more durability is important because we don’t want to dump any data. In these cases, queues act more like specialized databases so that if the service fails, the queue can reconstruct where it was and ensure messages are delivered, without losing messages or requiring other services to be available.
Say, for example, you have an ingest queue and are collecting data from several different clients or edge services. If you lose that valuable data, you will never have a chance to get it back again — or there will be high costs associated with reconstructing that data — so you want to save it and make sure it’s durably maintained and guaranteed to be delivered.
While storage is inexpensive, it’s not infinite and not infinitely inexpensive. When it comes to durability as a cost driver, it is a matter of how much you’re willing to spend on the storage and how durable you need your data to be in the queue.
How Throughput Impacts Queue Pricing
One of the most prominent queuing service cost drivers is the throughput of data. If your use case requires high data rates — either in volume or transaction counts — you need to select a queue that’s architecturally sound for that. While some queueing services aren’t guaranteed to deliver data in order because it’s faster and more cost-efficient to deliver out of order, others guarantee delivery and the order of delivery. Fortunately, Amazon has a billion flavors of queues, where there are different tradeoffs in terms of fan-out, delivery and order of delivery.
For example, depending on your application requirements, Amazon SQS offers two queue types with varying throughput features. Standard queues offer unlimited throughput, supporting “a nearly unlimited number of transactions per second (TPS) per API action.” FIFO queues, on the other hand, by default, “support up to 300 messages (send, receive or delete operations) per second.” As such, by batching the maximum number of messages per operation (10), FIFO queues can support up to 3,000 messages per second. However, if your use case requires higher throughput, high throughput mode can be enabled for FIFO on the Amazon SQS console. With SQS and many other queue services, delivery order and message deduplication are typical throughput trade-offs.
To achieve high throughput, you must scale message producers and consumers horizontally. By adding more clients, you essentially achieve linear gains in queue throughput. However, any high-throughput queue is going to get expensive, and as is the case with many queue cost drivers, you are making trade-offs on other features (i.e., performance) by increasing the throughput.
Fan-Out and Queue Pricing
Fan-out, or the number of clients that can consume your queue, is another important cost driver when it comes to selecting the right queuing service for your application.
Most queues are designed to have one publisher and one or more subscribers. Consequently, if you are on a microservices architecture, you only need a one-subscriber model because the first available instance is going to pick up the message and process it. For a broadcast event or a configuration change that multiple services need to know about, on the other hand, a pub/sub fan-out model, where you can publish once and multiple people receive a copy, is likely the better option.
An often-overlooked cost driver, fan-out is driven by the bandwidth limitation out to the subscribers to that queue. As a result, many companies fail to recognize that if they need high fan-out to multiple subscribers, their queuing service can become crazy expensive in a hurry. Consider Kinesis as an example here. Of course, there is a throughput limit on the input, but to fan that data out to all the different subscribers can be costly.
When selecting the queue for your application, fan-out is one of the cost drivers of which you have to be aware to ensure you’re not picking a service that’s going to bottleneck you in when you nail down your specific use case.
Delivery Delay
Not always directly linked to price, but another major consideration for selecting a queueing service is delivery delay. If your application requires low latency to fulfill its requirements, you need to be sure to select a queue that delivers content as soon as it is pushed onto the queue. Some queuing solutions, like Kinesis Firehose, will buffer data until a certain size is reached and then send the message.
Delivery Order and Duplication
Many queues achieve high throughput with multishard architectures that attempt to parallelize work. This can lead to messages being delivered out of order, or possibly delivered more than once, and your application must be aware of this and handle it. SQS is a good example of a service that offers a basic lower-cost option that doesn’t guarantee delivery order but does offer a FIFO option that will do so if you are willing to accept the performance loss and higher cost.
Frequency Views Can Affect Queue Pricing
Finally, think about your frequency views — especially if you’re going to opt for a managed service.
If you’re only using your managed queuing service for an hour a day, you’re burning a cloud instance or a cluster of instances behind the scenes. And while your service provider manages all of that for you, you’re essentially paying an hourly rate for those resources to sit there and run your queue or your broker.
Therefore, if you only need an hour of queue time a day, you might not want to use a managed service because you’re just burning CPU. However, if you have 24/7 load, you could save a significant amount of money going with a managed service, but you still might have to do a little bit of server maintenance to configure and operate it.
Unfortunately, because many queue services require a little bit of care, management and maintenance on the part of a DevOps team, some organizations might be better off paying a little bit more for a full-on managed service and allowing their service provider to bear the load of the operations costs.
In this penultimate post in this blog series, we touched on some of the most significant queue service cost drivers and how those can impact other features and the overall performance of queues. Whether your application requires durably maintained data, high throughput, high fan-out, 24/7 availability or some combination thereof, it’s important to understand how each element can — and will — impact your bottom line. Now that you know what can quickly ramp up the cost of your queuing service, it’s easier to define your requirements and work toward selecting the optimal queue.
Check out the fourth and final installment in this blog series. In the series conclusion, we highlight some best practices and final considerations for selecting a queue.
