[tonyhb]

We've built something similar at https://www.inngest.com — we allow you to build durable serverless functions that react to events (or run on a schedule).

The good thing about us is that you don't need to learn about events, subscribers, backoffs, idempotency etc. Instead, you write a single line and can deploy reliable event-driven functions to any provider, even at the edge. Most people are afraid of tackling event-driven architectures because it's too hard to set up, debug, build, make reliable, deploy - all the standard stuff that's frustrating.

When I say durable, I mean:

- Functions get their own state, retries, idempotency, throttling, etc.

- You can create steps within functions which have their own retries, similar to Temporal

- You can eg `sleep`, `sleepUntil` within a serverless function to handle queues or delayed jobs

- You can `waitForEvent` within functions to wait for other events which match arbitrary expressions. This lets you do magic things like "when a user adds something to their cart, wait for the checkout event from this user for 1 day. If the event is null/not received, send a reminder email". This is hard to do out of the box, but with us it's built in and takes a single line of code.

- We also store each event so you can do things like local replay, event versioning, schema management & governance, etc.

When you mention "distributed transactions", there's many ways to go. For us, we're working on CDC so that you can atomically react to actual DB transactions. For everything else, durability and retries becomes important.

There's a *lot* to talk about here. I'd love to discuss more in depth - shoot me an email if it's of interest! :)

[olivermrbl]

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 :)

[tonyhb]

Yep, Inngest does something similar — it can layer over any event stream (NATS, Kafka, GCP Pub/Sub, SQS/SNS, etc.) in order to subscribe to events & trigger functions. We provision that for so you don't need to manage anything when you sign up to us, though it's definitely flexible :)

That said you still need a state store and queue capable of future publishing internally to make things work; if you want to run anything durably, you're going to need to manage state. That's still flexible but a little less so — you need to choose both a queue and a backing state store to make that work.