Remix.run Logo
tomp 3 hours ago

Does it actually work?

In a past job, they tried to implement a similar thing on much lower scale with bidirectional database migrations.

Fortunately, they were mostly ran in one direction.

sanderjd 3 hours ago | parent | next [-]

IME, it works, but at the cost of a pretty large amount of overhead, both in performance and (I think more importantly) cognitive.

Honestly I never did come to a satisfying conclusion on whether I thought it was worth it. The teams I worked on that used it found it neither simple nor easy to use, and I was never sure whether we were really reaping the benefits of correctness in the face of failure at the scale we were running. We eventually migrated everything off of it, and everyone was happier, but perhaps (probably) we had more lurking bugs in distributed failure cases. But to my knowledge we never tracked down an incident to the kind of problem that temporal solves.

I guess I'd say that I like durable execution (or at least temporal specifically, it's the only system like this that I've used) in theory, but not really in practice.

KptMarchewa 3 hours ago | parent | prev | next [-]

The fintech (now bank) that I worked in couple of years ago utilized this pattern pretty effectively.

The overhead of doing something in this way is quite large, but, as this handled literal money, it was definitely worth it.

skywhopper 2 hours ago | parent | prev [-]

Yeah, I’ve seen it working. It does work well to implement a multi-system transactional workflow broken down into retryable steps. So, eg, if you are operating a SaaS and need a workflow for new customer signup to wait for multiple steps that might last for hours or days like: validate credit card info, wait for email confirmation, add entries to customer database, set up workspaces in downstream systems, spin up cloud resources, initialize systems, notify customer, start billing cycle, etc. and if any step fails, you might want to retry or send alarms or internal notifications, or roll back other steps, or kick off other workflows. Then you can define all of that, in code. Each step can be different runtimes run on different worker systems, etc, all coordinated through a central database.

You can scale the workflows up and down to as complex or simple as you want for whatever your business is. The example above is one I’ve seen, but it works on a smaller scale as well. But you have to write the implementation code in very specific ways to get the benefits, and the overhead ends up being very difficult to plan and reason about, and a lot of business logic actually gets hidden amongst the weeds of the tool’s overhead.