Hello Temporal Community!
I’m from the Sequin Stream team, and I wanted to share a tutorial we’ve created that addresses a common challenge: how to reliably trigger a Temporal workflow when data changes in your database.
The Problem You Might Have
You need to guarantee consistency between your database and Temporal workflows. Such that anytime a change happens in your database you know that a temporal workflow is executed.
As noted in a discussion about external DB events driving workflows, “There are situations where this becomes less clear though and there’s value in the ability to separate consumers of changes from the initial action.”
Traditional approaches often involve:
- Manually implementing the outbox pattern
- Setting up complex message brokers like Kafka or RabbitMQ
- Creating polling mechanisms that may miss events or be inefficient
Using CDC with Temporal
The tutorial demonstrates how to transactionally trigger a Temporal workflow when data changes in your database, ensuring consistency across services and building complex, transactionally-consistent workflows.
The approach uses:
- Sequin to detect database changes and deliver webhooks (though you can use any CDC / Trigger)
- A worker that receives these webhooks
- Temporal workflows that handle the business logic
In our example, we show how to trigger a workflow to ensure a user is deleted across multiple services as soon as the user is removed from the database. Sequin provides guarantees that the workflow is always triggered regardless of how the change is made, and then Temporal ensures the workflow executes reliably.
Why We Think This Matters
We believe this pattern is valuable because:
- It creates a clean separation between data changes and workflow triggers
- Sometimes it’s hard to ensure that changes to the database always flow through the API that triggers the Temporal workflow (or make Temporal the source of truth). This approach uses the database as the ultimate source of truth.
- It avoids many of the challenges of managing event queues in systems like Kafka
- You get transactional guarantees without having to hand-rebuild the outbox pattern
Check Out Our Tutorial
If you’re interested in implementing this pattern, check out our complete tutorial here:
We wanted to post into the community to make sure we can provide support here too and be present to answer any questions!