rich tusk
Has anyone had issues regarding de-duplicating events so that only one instance executes an event? I haven’t had the issue yet but can envision I will run into it at some point.
I read somewhere about potentially switching to a message broker which I think would help but wondering if there was anything else alongside?
With the message broker though I don’t think this provides a solution for duplicate events being emitted.
Many thanks
Liam
rich tusk
I might be making a mountain out of a molehill if medusa handles this under the hood and i'm mis-understanding the architecture, i'm just not entirely sure.
quiet hawk
Actually you might be right, if I have several instances with a LB , using same database, when a product is updated, which instance is goping to act like a subscriber for that event? top of my head: all of them
rich tusk
Actually you might be right, if I have several instances with a LB , using same ...
That was my thought I was wondering under the hood if there was a derived ID from the payload and event name and a check before setting a redis value but haven’t managed to find anything thus far.
How does that work in case of a race condition. I know I’ve seen bullMQ has a locking mechanism built in for concurrency so that should theoretically solve the execution part as long as the same event isn’t emitted X amount of times
magic igloo
Wouldn't having a central/single event bus redis solve this?
rich tusk
Wouldn't having a central/single event bus redis solve this?
Potentially as i'm not really that proficient in this realm so thought i'd ask the question
quiet hawk
yes @magic igloo you are right, Redis is there to act like an event bus.
sour lion
@quiet hawk @magic igloo
but redis isn't fully atomic there is still a chance to not complete the task?
and what to do when redis fail during the task there is no rollback
magic igloo
If redis fails or gets erased then i imagine that would be a problem, the default, red event bus, and workflow engine is the orchestration layer.
Technically it's an event-driven app, Redis drives the events
You could substitute Redis with something else probably. I haven't looked into it in the backend but the architecture is modular. It's made for you to be able to pick and choose what pieces you want.
If you’re concerned about redis failure and need a stronger solution, consider more robust, and proven/battle tested software with managed services. Although I don't think that this is necessary, and Redis will probably be just fine.