Hello, itslave, you wrote: a C>> At first, on systems of messages absolutely it is impossible to do protocols of a type a question-answer. Any attempts of the such result in because of complexity. I> it is possible and do. never , but the applicability range is wide enough. I saw even implementations of analogs TCP on messages, with flow control and other. It does not mean that it is good idea. While I for myself found two normal applications of queues: 1) Raskidyvanie of calculations or long asynchronous tasks on a computing cluster. 2) simple best effort fire-and-forget for external systems with notification messages about changes. The C>> If for any reasons a step Would start to brake, we can receive a row of interesting variants of succession of events. Queue starts to grow beyond all bounds, thus depending on a queue policy new messages can not be processed at all (if FIFO and is ). I> Normal queues so that they were I> - dimensionless I> - not I> - guaranteed high SLA on Read that I wrote. Queue, and the output agent because of what depth of queue starts to grow breaks not. Thus the system of messages can perfectly work. And then especially ridiculously happens, if messages in the heart of queue cannot be processed because of that any more that the objects connected to them ceased to be actual. I> at such input, the probability of the described scenario is minimum (and all in distributed systems rests against probabilities finally), but allows loading on and logically to decouple and (that in addition, allows to do 0-downtime update for ). It still becomes and without systems of messages is better. And on a word "decoupling" I now generally at once beat in a physiognomy. C>> Thirdly, reliability question - if the message is erraticly remote from queue, it is very difficult to understand that there generally happened. I> a question exceptional to monitoring and aggregation of dens. At me their terabyte at an o'clock on some systems. But speech not about it, a problem that if the message is remote in many systems on messages not clearly in what state became is system. Whether the task connected to the message has been made? The C>> Fourthly, appears a failure template - "the poisoned message". 1. At message handling there is an error and system it puts reversely in queue. Further goto 1. If such messages some tens they easy hammer in the remaining traffic. I> as I already marked above - retries + dlq treats such variants. Though performance can degrade, if it is more zero (that not to send message in dlq at the first error). Besides, read that I wrote. There is a poisoned message which causes an error at handling (well here a bug in the code of the output agent). As this message does not prove to be true, queue very obligingly does to it retry, again completed by an error. If retry' it is a lot of, the poisoned messages force out all remaining, even if speed of their arrival the insignificant. DLQ here generally unless only for after all breaks. The C>> Well and system of messages is a uniform point of a failure, not bad such things to minimize. I> all rests in SLA. Frequently queues - distributed systems, with SLA above than at suppliers-consumers of this queue. Oh, well it is not necessary. Vendors can give SLA in 146 %, only after all all the same all falls.