3 ms·

Great write-up. Back-pressure would be a useful concept to add.

sudhirj 6y ago
Thought it was already implicit in the capacity decoupling, could you elaborate a bit more / add an example. I’ve always thought back pressure isn’t applicable to queues because there’s no pressure to begin with, front or otherwise.
- encoderer 6y ago
  In most cases, queues are going to be a lot faster than whatever they are feeding into. If you are doing something like sending every SQS message to a Lambda with infinite concurrency then, sure, but many queues are feeding into a compute or persistence layer of some kind. Back-pressure here would mean that emitters of messages into your queue behave differently when there is an excessive number of messages waiting to be processed. For example: - If it's a job queue, load-shed less important jobs until the queue is healthy. - If you are ingesting a high volume of messages, be more aggressive with batching them together before inserting as a single queue message.
  - sudhirj 6y ago
    Ah, got it. I’m not entirely sure I want to put that in, though. The message I’m “preaching” is that you have full decoupling with queues - not sure that should be diluted. Wouldn’t this kind of checking defeat the purpose of using the queue in the first place? It seems unlikely that Amazon would stop selling stuff just because the order-confirmation-email-sending-service was backed up, for instance. The point of using SQS would be that the sales system wouldn’t have to care.
    - encoderer 6y ago
      In the universe of message queues, an email-per-sale queue is not going to be your problem. Think of the queue-as-message-bus pattern -- very common. You don't want to have a service with millions of pending messages to process, it forces you into painful, slow recovery, or making the tough choice of dropping everything. Anyway, great write up, and happy new year!
- kag0 6y ago
  For example, in a near-real-time application it may be better to fail than to have overly delayed message delivery. If a queue becomes too large then we get the idea that messages are not being consumed fast enough (in near-real-time). In this situation continuing to send more messages is just going to make the problem worse (although this is more like a circuit-breaker/fail fast than back-pressure). Also it might be better from a business logic perspective to inform the user of the problem than to apply their input at a later time (eg. a game where user input is unlikely to be intended for anything but the very recent game state).

Thought it was already implicit in the capacity decoupling, could you elaborate a bit more / add an example. I’ve always thought back pressure isn’t applicable to queues because there’s no pressure to begin with, front or otherwise.

encoderer 6y ago
In most cases, queues are going to be a lot faster than whatever they are feeding into. If you are doing something like sending every SQS message to a Lambda with infinite concurrency then, sure, but many queues are feeding into a compute or persistence layer of some kind. Back-pressure here would mean that emitters of messages into your queue behave differently when there is an excessive number of messages waiting to be processed. For example: - If it's a job queue, load-shed less important jobs until the queue is healthy. - If you are ingesting a high volume of messages, be more aggressive with batching them together before inserting as a single queue message.
- sudhirj 6y ago
  Ah, got it. I’m not entirely sure I want to put that in, though. The message I’m “preaching” is that you have full decoupling with queues - not sure that should be diluted. Wouldn’t this kind of checking defeat the purpose of using the queue in the first place? It seems unlikely that Amazon would stop selling stuff just because the order-confirmation-email-sending-service was backed up, for instance. The point of using SQS would be that the sales system wouldn’t have to care.
  - encoderer 6y ago
    In the universe of message queues, an email-per-sale queue is not going to be your problem. Think of the queue-as-message-bus pattern -- very common. You don't want to have a service with millions of pending messages to process, it forces you into painful, slow recovery, or making the tough choice of dropping everything. Anyway, great write up, and happy new year!
kag0 6y ago
For example, in a near-real-time application it may be better to fail than to have overly delayed message delivery. If a queue becomes too large then we get the idea that messages are not being consumed fast enough (in near-real-time). In this situation continuing to send more messages is just going to make the problem worse (although this is more like a circuit-breaker/fail fast than back-pressure). Also it might be better from a business logic perspective to inform the user of the problem than to apply their input at a later time (eg. a game where user input is unlikely to be intended for anything but the very recent game state).