I am willing to use Oban to implement the Outbox pattern, and would like to what are the best settings for this scenario?
Could you point us to the description of the Outbox pattern you’re referring to please? I would like to learn more, but there are so many results after I tried searching for it.
I want to to guaranty the publication of the domain events of my app to a Broker that is, one of pattern used is this one ( Outbox pattern, saving the state and the event in the same db within same transaction ), this way you will not loose your events in case of failure they will kept in DB
I have used that pattern before. I’m not sure what you are looking for though. It boiled down to inserting an Oban job within a transaction that would latter send an email or a message to a Kafka queue.
Implementing the pattern is just making sure that you do not actually send messages to the external world (besides the DB obviously) during the transaction but just insert something that will later produce a side effect. But you can do it however you want.
It’s also great for testing because you just have to assert that your business logic enqueues a job when it should. And another independent test of your perform function that ensures that a message is properly sent.
Something to consider though is that after the transaction, your app will consider the message to be sent, but it may be delayed by some time, or fail. So obviously the code should account for delays, be safe against race conditions, and use a sufficient amount of retries when the Oban jobs fail.
1 Like
