7 ms·
I find it interesting that the article claims eventual consistency, but also best effort ordering. The consistency in a queue is surely made of two parts: count
by bluecmd 11y ago
I find it interesting that the article claims eventual consistency, but also best effort ordering. The consistency in a queue is surely made of two parts: count and order. To not have duplicates is nice, but if ordering is not guaranteed - is this really a queue? Seems like it's a Something In Something Out, or "a pile" or something. Again, curious about what the evental consistency guarantee is referring to.
Not saying it cannot be useful - for work distribution it will surely work - but it needs to be considered for your usecase that you will need to be able to process messages in an unlimited unordering. Process a delete action before a create for example.
- antirez 11y agoWhat is eventually consistent is the job state: it means that jobs are removed only when they are successfully delivered at least one time. Best effort ordering does not mean no ordering btw. Use cases for which strict ordering is needed are rare, and it is possible to build order out of an unordered queue if strictly needed (especially since, when strict ordering is needed, usually you have a source of truth to maintain the state of the application, that happens to be a strictly consistent store). The cost of ordering is huge in terms of design, and benefits just an handful of use cases. So I think best effort ordering is one of the best Disque assets.
- bluecmd 11y agoAh OK. This might sound harsh, but so the guarantee you have is that the data will not be lost? That's a pretty weak guarantee no? Also, best effort implies no ordering in the worst case no? I always try to judge systems when the world isn't peaches.