[jmcnevin]

We've been using Temporal for the past year and have found it to be an absolute joy.

Being able to model business processes--some of which may take multiple _years_, and require human approval/rejection steps--using procedural go/java/js, and knowing that once that function starts executing, it is basically indestructible (barring the complete destruction of temporal's backend database), is just really cool. Being able to outsource a lot of the complexity involved in using event sourcing to manage distributed transactions frees up our developers to worry about just the high-end business logic.

Congrats to the team! I'm excited to see Temporal gaining some more traction.

[swyx]

we should put this comment on our landing page and call it a day

[MaknMoreGtnLess]

> outsource a lot of the complexity involved in using event sourcing

Temporal uses/implements/helps implement event sourcing easily?

[swyx]

we use event sourcing under the hood for its fault tolerance and scalability (and tracing/observability). it’s abstracted away for you by our SDKs.

in other words when you use us you get the main benefits of ES without the downside of having to code it up yourself, which is a common pitfall of homegrown ES systems.

[MaknMoreGtnLess]

That's fair but I have a question:

If I DID want to get access to the event sourcing mechanisms under the hood - can I?

My hypothesis is that I can use Temporal to implement high quality DDD pipelines that follow CQRS - having explicit access to the event sourcing mechanisms would be fantastic!

Otherwise, it's an issue as most DBs can be argued to use some form of event sourcing mechanisms under the hood but they arn't built to be exposed outside the DB - hence an event sourcing mechanism has to be reimplemented (hence pitfall of homegrown ES systems).

What are your thoughts?

[swyx]

you could, by directly accessing the backing db, but we dont encourage that. The other way you could do it is read-only access by polling our event history APIs - that would be doable.

i try to say "we use event sourcing under the hood" rather than "we do event sourcing for you" for this reason - if you use us and expect the same level of control as homegrown youre gonna be disappointed

[MaknMoreGtnLess]

understood.

What's the design pattern you recommend Temporal users use to implement multiple consumers?

Usecase: Handle a large, spiky backlog by dynamically sharding the consumer input, starting and putting multiple consumers to work until the backlog is within nominal specs.

Eg: Shipping orders during a sales event. Each S&H order takes the same response time but multiple S&H orders can be parallelized and there are a few hundred thousand orders pending. Of course, S&H order can fail, in which case they are restored to the pending state after a timeout or loss of a lock