|
|
|
|
|
by creztoe
2083 days ago
|
|
This kind of confuses me a bit. Why would you want to turn Pub/Sub into a queue? How badly does this affect message acknowledgment and retries? I assume just a huge hit to latency. This seems like a horrible idea for anyone expecting to use multiple subscribers or expecting to chunk multiple messages per request. Services relying on Pub/Sub should be idempotent anyway. If you need to work around that for some reason, you are better off dumping messages from your subscriber into RabbotMQ or Redis for processing and use a Subscriber/Scheduler/Worker pattern. |
|
Idempotent is a good idea even in a system like this. But it is not always possible as your upstream data sources may be something very different.