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.

Yes indeed. Attaching below a couple of references from my exploration:

Transactional outbox pattern:

- https://microservices.io/patterns/data/transactional-outbox....

- https://softwaremill.com/microservices-101

- https://brandur.org/job-drain

A pattern similar to the one I mention using cache:

- https://masstransit-project.com/articles/outbox.html

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.

Medusa is a headless API, so you are free to consume it from wherever you want whether it be a React-based storefront, a C# backend, or something third - there's really no limitations.

But the source code of the open-source project is written in Node.js, so if you looking to contribute, you are forced to write JS.

Re SDKs, there's an official JS SDK and a community-led Flutter SDK - that I know of. The former can be found in the GitHub repository here: https://github.com/medusajs/medusa/tree/master/packages/medu...

Disclaimer, I am co-author of the project.