Operations. At my $bigCo we are always rolling our own ops tooling for queues, as it’s more than just “reprocess message”; there is always some business logic that separates different types of consumers/destinations, and so q management is never straightforward. Might be a differentiable feature.
I’ll give you a real example, and it aligns with one of your feature goals that you mentioned elsewhere in these threads: allow you to rate limit without change on the client side.
I have a workload that processes transactions for P external partners (P>1000) in a market with diverse technology sets; some partners are aggregated behind MSPs and some we integrate with directly, and so those P partners represent say 500 unique destinations. This workload handles < 100 line-of-business transaction types, spread across the partners; some support them all, some support only a few, and their implementations may be standard/consistent across transactions or their may be unique implementations.
This is not a strange architecture, it represents the fact that every business-system has a lifecycle, there are legacy xml cruft and shiny graphql both exposed to the world and sitting next to each other, making money, and nearly every integrator has this. These systems go down, or networks become unavailable, or they perform maintenance, or maybe they can only support 2 concurrent connections - and every partner is different. Some MSPs come in and get some % of the market for handling this for businesses that don’t have the capability, but there are many that do.
If you were in the business of exposing products that use these services, would you want your engineers having to care about any of it? Me neither, and so it is CRITICAL that we operationalize it, which for a store-and-forward integration workload basically ends up being an operational tool for queues and their destinations.
I do not however find any tools that meet our requirements, which are simply “allow an operations/support team to manage transaction T for partner P who may be hiding behind MSP M” which includes rate limiting, circuit breaker, observability, routing, deployment, billing etc etc. This is IMO tied very closely to the queue - it is in fact the workload’s primary data store - and I do not understand why queue providers don’t differentiate their offerings with this kind of management capability.
If I think about a business journey from startup to enterprise, maybe a small shop does not need this - they only support a small number of transactions and a small number of partners. As they grow, this requires engineering, and so they just build the tools they need to scale. But it doesn’t have to be that way.
10m requests for $4.
You will need hundreds of millions of requests per month for it to be noticable.
And can an implementation like this even help you at that point?