[Uber Open Summit 2018] Cadence: The Only Workflow Platform You'll Ever Need

Uber Engineering · 44K views · 2018 · 35:44

Open on YouTube

Distributed systemsSoftware architecture & designCloud, DevOps & reliabilitytalk

Why Stack Overflow recommends it

Stack Overflow users link it when answering questions about durable workflows, queues, sagas and microservice orchestration, as an introduction to the Cadence/Temporal programming model.

Recommended by 2 people across 4 different months, 2019 to 2022.

What it is

A 2018 Uber Open Summit talk by engineer Maxim Fateev introducing Cadence, Uber's open source workflow platform for building fault-tolerant, long-running applications. It covers the programming model, where workflow code and its local state stay durable across process failures.

What people said

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Is there a mature Java Workflow Engine for BPM backed by NoSQL?”

Yes, Temporal Workflow [LINK] has pluggable persistence and runs on Cassandra as well as on SQL databases. It was tested to up to 100 Cassandra nodes and could support tens of thousands of events per second and hundreds of millions of open workflows. It allows to model your workflow logic as plain old java classes and ensures that the code is fully fault tolerant and durable across all sorts of failures. This includes local variable and threads. See this presentation [this video] that goes into more details about the programming model.

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Looking for architecture to download big files”

I would recommend using Cadence Workflow [LINK] for your use case. Yes, you can build your process using RabbitMQ, but you end up implementing a lot of features that Cadence provides out of the box. Cadence offers a lot of other advantages over using queues for task processing. Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running tasks Heartbeating to checkpoint progress of long running tasks. Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic in

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Akka: Adding a delay to a durable mailbox”

Temporal Workflow [LINK] is capable of supporting your use case with minimal effort. You can think about it as a Durable Actor platform. When actor state including threads and local variables is preserved across process restarts. Temporal offers a lot of other features for task processing. Built it exponential retries with unlimited expiration interval Failure handling. For example, it allows executing a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic in case of unrecoverable failure

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Many small queues in Kafka - how to maintain scale-out load-balancing?”

I don't think Kafka is a good good fit for such use cases. It wasn't designed for huge number of queues and downstream consumers. It also relies on time based retention which doesn't play well with lengthly consumer downtimes. I would recommend looking into Cadence Workflow [LINK] to implement your application. Cadence offers a lot of other advantages over using queues for task processing. Dynamically created task queues. The number of queues is unlimited. Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “How to propagate exception on event-driven/message queue microservice?”

I would recommend Cadence Workflow [LINK] which is much more powerful solution for microservice orchestration and provides exception handling propagation across long running operations out of the box. It offers a lot of other advantages over using queues for your use case. Built it exponential retries with unlimited expiration interval Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic in case of unrecoverble failures ( SAGA [LINK] ) Gives complete visibility into current state of the update. For example when using queues all you know if there are some messages in a queue and you ne

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Message queuing per tenant”

It is not possible to guarantee exactly once processing in your case. What should the messaging system do when task processing is completed, but due to hardware failure the acknowledgement is not delivered? It can either drop the message (practically loosing the customer request) or redeliver it (which violates exactly once). There should be a way to check if request was already processed. It would allow you make the task processing idempotent. BTW I think queues are not good fit for your use case. Check out Cadence Workflow [LINK] that would give you a lot of features and visibility into processing out of the box. Cadence offers a lot of advantages over using queues for task processing. Bui

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “When to use - Delayed Job vs RabbitMQ”

Another option is to use task orchestration system like Cadence Workflow [LINK] . It supports both delayed execution and queueing, but provides higher level programming model and tons of features that neither queues or delayed execution frameworks. Cadence offers a lot of advantages over using queues for task processing. Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Store and forward design pattern with multiple instances of a microservice”

I would advise against NIH [LINK] syndrom and take a dependency on a mature technology that delivers all your reliability requirements out of the box. Cadence Workflow [LINK] is capable of supporting your use case with minimal effort. Cadence offers a lot of features that are hard to match building custom task orchestration solution: Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compen

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Push Data onto Queue vs Pull Data by Workers”

I would recommend Cadence Workflow [LINK] instead of queues as it supports long running operations and state management out of the box. Cadence offers a lot of other advantages over using queues for task processing. Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic in case of unrecoverble failures ( SAGA [LINK] ) Gives complete visibility into current state of the update

Recommends Maxim Fateev · 2019-06 · Stack Overflow · on “Task queue using rabbitMQ”

You are essentially implementing stateful orchestration. I would recommend looking into Cadence Workflow [LINK] that capable of supporting your use case with minimal effort. Cadence offers a lot of other advantages over using queues for task processing. Built it exponential retries with unlimited expiration interval Failure handling. For example it allows to execute a task that notifies another service if both updates couldn't succeed during a configured interval. Support for long running heartbeating operations Ability to implement complex task dependencies. For example to implement chaining of calls or compensation logic in case of unrecoverble failures ( SAGA [LINK] ) Gives complete visib