You're absolutely right, patterns are just like a way of communication.
why bring up the message queue pattern here?
How do you communicate to a message queue?
What compromises do you make when sending events into the message queue?
The retry pattern is meant for resilience.
Task queues (like Celery) already have the implementation of the retry pattern, and task queues require MQs (or brokers) to do their job.
So, to achieve a greater level or resilience, both a task queue and an MQ are necessary.
Actually, this pattern goes with couple of other design decisions (like microservices and event-driven-architecture).
Because of that, the biggest compromise when using such architecture is that your program would often need a complete rewrite.
Say for the previous example (of using a transaction to place an order), you would instead create an event "order_created".
This will trigger other services like shippingService & chargingService to do the next steps.
Suppose the chargingService failed in the middle, it will retry again (cuz the message of "charging_credit_card" won't leave the queue for couple of retries). If it ultimately fails, it will trigger another event for rolling back across multiple services.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You're absolutely right, patterns are just like a way of communication.
The retry pattern is meant for resilience.
Task queues (like Celery) already have the implementation of the retry pattern, and task queues require MQs (or brokers) to do their job.
So, to achieve a greater level or resilience, both a task queue and an MQ are necessary.
Actually, this pattern goes with couple of other design decisions (like microservices and event-driven-architecture).
Because of that, the biggest compromise when using such architecture is that your program would often need a complete rewrite.
Say for the previous example (of using a transaction to place an order), you would instead create an event "order_created".
This will trigger other services like shippingService & chargingService to do the next steps.
Suppose the chargingService failed in the middle, it will retry again (cuz the message of "charging_credit_card" won't leave the queue for couple of retries). If it ultimately fails, it will trigger another event for rolling back across multiple services.