How NUMI uses Trigger.dev to build resilient systems

Using Trigger materially changed the way we architected our code. Not because we had to work around it, but because it encouraged us to write code the way our system's logic wanted to be written.

We needed observability in our workflows, and the ability to re-run them in the case of failure. Using the naive solution: keeping all of our business logic inside of webhook endpoints, was brittle. Oftentimes integrations would be down, or APIs would update. Since our application integrates heavily into other applications, getting the data to be consistent across multiple stores is surprisingly difficult.

We needed a solution that could allow us to execute idempotent code and get to “eventually consistent” in the case of:

• Inevitable bugs in our integration logic
• API outages
• Upgrades

Using Trigger materially changed the way we architected our code. Not because we had to work around it, but because it encouraged us to write code the way our system's logic wanted to be written.

We now think more in terms of steps and side effects, rather than keeping all of the application logic in a single endpoint.

This is great for a distributed system product like ours, where different triggering events should cause sub-workflows to fire. With Trigger we can model these nuances easily, and compose complex workflows from atomic Trigger tasks.