olivermrbl

> What would happen if the orchestrator was unable to update the remote shared cache outbox after a local exception/rolled back transaction

To be sure, I understand your question, you are referring to the following scenario:

- Start global transaction

- Create shared cache entry

- Add events to the shared cache

- Local transaction fails

- Orchestrators starts rolling back local transaction

- Attempts to delete shared cache entry <-- THIS ONE FAILS

To ensure we don't have stale events in the cache, I would add a TTL, which is configurable for each job (such that you can have long-living events). So in case the orchestrator fails to delete the cache entry, they would be invalidated at some point by exceeding its TTL.

Thanks for chiming in!

Although I appreciate your detailed walkthrough of Inngest (sounds amazing), I wonder if it is the right fit for us.

One of our guiding product principles is to always build framework agnostic solutions, allowing our users to choose the best tools and providers for their needs. We do this by creating abstractions for each functional area of our domain and element of the stack.

In the context of events infrastructure, developers should be able to use Redis, RabbitMQ, Kafka, and even Inngest interchangeably.

I would love to hear more about your experience with CDC. As far as I understand, this is an alternative to simply polling the outboxes. Will shoot you an email :)

On the alternative solution, it's worth stressing, that it does not have to be a cache service. Any key/value store would do.

Don't hesitate to reach out. We are amid extending our B2B capabilities, so it would be super interesting to learn about your client's requirements. And your own.