4 ms·

I don't understand the purpose of at-most-once semantics in practice: So, you've got some process where you don't care if the message goes through, but you're w

I don't understand the purpose of at-most-once semantics in practice: So, you've got some process where you don't care if the message goes through, but you're willing spend money on the compute/storage for it anyway? Why bother? If you're designing a system with those semantics, is that because you're hoping that it's exactly-once: 99.999% of the time -- wink, wink, nudge, nudge so that your handlers don't have to be idempotent? What's the fallback plan for the day that all of your messages go into a networking blackhole?

willvarfar 12y ago
I work in SMS sending, and every link in the chain has to reason about how they fail. If there is a failure, it is better that the message is dropped than that it gets resent duplicated. It would be a bad system indeed if a failure to write a log line (say) caused a retry loop that resent the message again and again...
- politician 12y ago
  Many at-least-once systems support dead letter queues natively, and if not, support isn't hard to add on yourself.
jaimeyap 12y ago
I could imagine at most once being good for something like a ping or a heartbeat. Or even a "this is the current version of some piece of data". And if your consumers are prone to failing to ack and you don't want to gum up the queue with retries. But your point stands that it is certainly not what we want in the lions share of use cases. I guess that's why the default semantics are at least once. With at most once being a configurable option.
deleted 12y ago
[deleted]
stevewepay 12y ago
I want a message queue to hold credit card authorization requests. I want to ensure that the authorization requests occur at most once, since having a customer's credit card charged twice is infinitely worse than not charging the card. If the request never goes through, then I can always get the customer to try again, but if it gets charged more than once, then it's a huge headache, and our customers get extremely angry and lose confidence that we know what we're doing.
- IgorPartola 12y ago
  Don't you store the result of the authorization in your persistent storage? If you do, you can check whether you need to do the authorization again.
- jaimeyap 12y ago
  Credit card authorization might be better suited to a synchronous request, versus going through a message queue.
  - Rapzid 12y ago
    It doesn't really matter either way. Unless you are using distributed transaction protocols, you pretty much MUST store-and-forward and have idempotent processes in the consumer/receiver to guarantee something happens. Usually the easiest way is to generate a transaction ID, such as a UUID, at the very start and use it end-to-end as indicated by the earlier nonce comment. Then each step along the way can either locally dedupe, or refer to a shared database/API with it.
    - jaimeyap 12y ago
      Well one difference is being able to easily propagate failures end to end. Agreed about idempotent processes in the "consumer" processes. But I generally prefer marking an end user session in a persistent store before propagating the request for payment (effectively acting as a sticky current transaction ID), and making synchronous requests down the chain versus generating a transaction ID and doing a bunch of async message queuing. It's just easier to know when something didn't work and display the appropriate user feedback. But your point is valid.
robotresearcher 12y ago
Soft real time data. Anything that would be out of date by the time you had timed out and resent. For example a packet of range data from a robot. Drop one? Worthless now, but another one will be along in 50 msec or so.
- laichzeit0 12y ago
  Why would you use a queue instead of a topic for a use-case like this?
  - robotresearcher 12y ago
    From the point of view each of the subscribers to a topic, they see a queue.
- politician 12y ago
  Telemetry from an external data source wouldn't be delivered from a queue, it'd be published into a queue. Think IoT into an AWS Lambda instance -- you've already paid the micro-cents to handle the request, so why not just forward it into Kinesis? (How does putting that data into a lossy queue save you time/money/effort?) EDIT: Misread your example. The idea is that the robot has an outgoing buffer containing time-series data that it tries to publish on a best-effort basis? In that example, it seems like a ring buffer would be a better solution than a messaging system.
  - robotresearcher 12y ago
    A ring buffer of length one minimizes latency.
  - angersock 12y ago
    Another example of this sort of behavior was the netcode common to Quake and many other shooters--since lots of history is sent as full state instead of deltas, it's "okay" to have lost packets. It's not ideal, and it'll screw up certain types of things that really, really want a contiguous history of events, but for normal play it's perfectly fine. When doing client-side prediction, then it may become useful to have historical data, but as my sibling post suggests, a ring buffer of length one minimizes latency. It actually might be interesting to see a writeup on multiplayer games viewed through the lens of eventually-consistent distributed databases.
jordanb 12y ago
A lot of sensor data is like this. Missing a reading is not ideal but not the end of the world.
the_mitsuhiko 12y ago
> I don't understand the purpose of at-most-once semantics in practice: So, you've got some process where you don't care if the message goes through, but you're willing spend money on the compute/storage for it anyway? Why bother? For instance because the time for retransmission is higher than what someone (say an HTTP request) is going to wait for.

willvarfar 12y ago

I work in SMS sending, and every link in the chain has to reason about how they fail. If there is a failure, it is better that the message is dropped than that it gets resent duplicated. It would be a bad system indeed if a failure to write a log line (say) caused a retry loop that resent the message again and again...

politician 12y ago
Many at-least-once systems support dead letter queues natively, and if not, support isn't hard to add on yourself.

jaimeyap 12y ago

I could imagine at most once being good for something like a ping or a heartbeat. Or even a "this is the current version of some piece of data". And if your consumers are prone to failing to ack and you don't want to gum up the queue with retries. But your point stands that it is certainly not what we want in the lions share of use cases. I guess that's why the default semantics are at least once. With at most once being a configurable option.

deleted 12y ago

[deleted]

stevewepay 12y ago

I want a message queue to hold credit card authorization requests. I want to ensure that the authorization requests occur at most once, since having a customer's credit card charged twice is infinitely worse than not charging the card. If the request never goes through, then I can always get the customer to try again, but if it gets charged more than once, then it's a huge headache, and our customers get extremely angry and lose confidence that we know what we're doing.

IgorPartola 12y ago
Don't you store the result of the authorization in your persistent storage? If you do, you can check whether you need to do the authorization again.
jaimeyap 12y ago
Credit card authorization might be better suited to a synchronous request, versus going through a message queue.
- Rapzid 12y ago
  It doesn't really matter either way. Unless you are using distributed transaction protocols, you pretty much MUST store-and-forward and have idempotent processes in the consumer/receiver to guarantee something happens. Usually the easiest way is to generate a transaction ID, such as a UUID, at the very start and use it end-to-end as indicated by the earlier nonce comment. Then each step along the way can either locally dedupe, or refer to a shared database/API with it.
  - jaimeyap 12y ago
    Well one difference is being able to easily propagate failures end to end. Agreed about idempotent processes in the "consumer" processes. But I generally prefer marking an end user session in a persistent store before propagating the request for payment (effectively acting as a sticky current transaction ID), and making synchronous requests down the chain versus generating a transaction ID and doing a bunch of async message queuing. It's just easier to know when something didn't work and display the appropriate user feedback. But your point is valid.

robotresearcher 12y ago

Soft real time data. Anything that would be out of date by the time you had timed out and resent. For example a packet of range data from a robot. Drop one? Worthless now, but another one will be along in 50 msec or so.

laichzeit0 12y ago
Why would you use a queue instead of a topic for a use-case like this?
- robotresearcher 12y ago
  From the point of view each of the subscribers to a topic, they see a queue.
politician 12y ago
Telemetry from an external data source wouldn't be delivered from a queue, it'd be published into a queue. Think IoT into an AWS Lambda instance -- you've already paid the micro-cents to handle the request, so why not just forward it into Kinesis? (How does putting that data into a lossy queue save you time/money/effort?) EDIT: Misread your example. The idea is that the robot has an outgoing buffer containing time-series data that it tries to publish on a best-effort basis? In that example, it seems like a ring buffer would be a better solution than a messaging system.
- robotresearcher 12y ago
  A ring buffer of length one minimizes latency.
- angersock 12y ago
  Another example of this sort of behavior was the netcode common to Quake and many other shooters--since lots of history is sent as full state instead of deltas, it's "okay" to have lost packets. It's not ideal, and it'll screw up certain types of things that really, really want a contiguous history of events, but for normal play it's perfectly fine. When doing client-side prediction, then it may become useful to have historical data, but as my sibling post suggests, a ring buffer of length one minimizes latency. It actually might be interesting to see a writeup on multiplayer games viewed through the lens of eventually-consistent distributed databases.

jordanb 12y ago

A lot of sensor data is like this. Missing a reading is not ideal but not the end of the world.

the_mitsuhiko 12y ago

> I don't understand the purpose of at-most-once semantics in practice: So, you've got some process where you don't care if the message goes through, but you're willing spend money on the compute/storage for it anyway? Why bother? For instance because the time for retransmission is higher than what someone (say an HTTP request) is going to wait for.