3 ms·

I would still view it as many to one. Visibility timeouts are for concurrency. Semantically speaking I would consider one consumer with n concurrent workers as

I would still view it as many to one. Visibility timeouts are for concurrency. Semantically speaking I would consider one consumer with n concurrent workers as one consumer function/service. In workflow terms, a SNS is a fanout, and SQS is a queue.

andrew_ 4y ago
You can subscribe multiple lambdas to an SQS queue. It's not recommended, but it's doable. many-to-many or many-to-one depends on your choices of infrastructure.
- elsurudo 4y ago
  Yes, but only one of them will receive the message.
  - andrew_ 4y ago
    Only one would receive a particular message, but all will receive messages.
    - elsurudo 4y ago
      That's true, but I wouldn't say that fits the definition of 1:N messaging. Just as the name says, it's a queue.
- specialp 4y ago
  I guess we can debate the semantics of it because it is technically possible. But it is terrible design to have a SQS to many different consumers. If someone did that I would reject it on review. In any proper usage of SQS it is many to one.
  - andrew_ 4y ago
    there are edge cases where that's desirable. I won't enumerate them here but they're discoverable on the Googles. I also would advise against that kind of passionate adherence to infrastructure dogma, taking a more analytical approach to review.
    - specialp 4y ago
      If you could name even one I would remove the "dogma". I cannot think of why anyone would want to do that. And if someone did want to do that they would have to have a very compelling reason to complicate what is usually an easy thing (One action listening on a queue)
  - afandian 4y ago
    How do you scale out processing if you can't have more than one consumer?
    - specialp 4y ago
      I am not referring to multiple homogeneous consumers processing a queue. That is fine. You have a pool of consumers that can pick up from the queue. That is still considered one entity/actor. The people here are proposing having multiple heterogeneous consumers consume from the queue. That is bad.

andrew_ 4y ago

You can subscribe multiple lambdas to an SQS queue. It's not recommended, but it's doable. many-to-many or many-to-one depends on your choices of infrastructure.

elsurudo 4y ago
Yes, but only one of them will receive the message.
- andrew_ 4y ago
  Only one would receive a particular message, but all will receive messages.
  - elsurudo 4y ago
    That's true, but I wouldn't say that fits the definition of 1:N messaging. Just as the name says, it's a queue.
specialp 4y ago
I guess we can debate the semantics of it because it is technically possible. But it is terrible design to have a SQS to many different consumers. If someone did that I would reject it on review. In any proper usage of SQS it is many to one.
- andrew_ 4y ago
  there are edge cases where that's desirable. I won't enumerate them here but they're discoverable on the Googles. I also would advise against that kind of passionate adherence to infrastructure dogma, taking a more analytical approach to review.
  - specialp 4y ago
    If you could name even one I would remove the "dogma". I cannot think of why anyone would want to do that. And if someone did want to do that they would have to have a very compelling reason to complicate what is usually an easy thing (One action listening on a queue)
- afandian 4y ago
  How do you scale out processing if you can't have more than one consumer?
  - specialp 4y ago
    I am not referring to multiple homogeneous consumers processing a queue. That is fine. You have a pool of consumers that can pick up from the queue. That is still considered one entity/actor. The people here are proposing having multiple heterogeneous consumers consume from the queue. That is bad.