Yes, this is the same as buying a unit and renting as in my original post.
1,734 karma · joined December 18, 2013
tony@inngest.com
They build good stuff and care.
Other than that, yes, durable execution does all of this for you.
TLDR on Durable Endpoints: you can automatically use steps in API endpoints which checkpoint state in the BG, and then retry on failure. This means you can run jobs in the background _somewhat_ transactionally (somewhat because there's delay between checkpointing) to minimize any tradeoffs here. And, if you want full transactionality, don't buffer checkpoints in the BG and instead do it synchronously.
Also, Redis is good for medium scale load. We're hitting millions of RPS (aggregated) on our services (I work at Inngest) and it doesn't scale so well at this load, at all. We had to invest in other infra.
IOW, doesnt look as bad as the title suggests?
Yes... but people can only focus on one thing at a time. We don't have 360 vision. We have blind spots! We don't even know the exact speed of our car without looking away from the road momentarily! Vision based cars obviously don't have these issues. Just because some cars are 100% vision doesn't mean that it has to share all of the faults we have when driving.
That's not me in favour of one vs the other. I'm ambivalent and don't actually care. They can clearly both work.
If you are changing the interface, though, that would mean a contract change. And if you're changing the contract, surely you wouldn't be able to even use the old tests?
This isn't really a go problem at all. Any contract change means changing tests.
I strongly believe that being obvious about steps with `step.run` is important: it improves o11y, makes things explicit, and you can see transactional boundaries.
I just figured that the exactly once semantics were so worth discussing that any external side effects (which is what orchestration is for) aren't included in that, which is a big caveat.
Want to send an email, but the app crashes before committing? Now you're at-least-once.
You can compress the window that causes at-least-once semantics, but it's always there. For this reason, this blog post oversells the capabilities of these types of systems as a whole. DBOS (and Inngest, see the disclaimer below) try to get as close to exactly once as possible, but the risk always exists, which is why you should always try to use idempotency in external API requests if they support it. Defense in layers.
Disclaimer: I built the original `step.run` APIs at https://www.inngest.com, which offers similar things on any platform... without being tied to DB transactions.
You: Want to be part of a fast growing startup that is changing how developers build software.
- Distributed Systems, Execution Engineer - San Francisco
- Product Engineer - Full Stack - San Francisco, Remote US
- Content Engineer, Docs - Remote US
- Product Marketer - San Francisco
- Dev Rel - San Francisco
Roles: https://innge.st/hn-july-25-hiring
About working @ Inngest: https://innge.st/hn-july-25-info
0% financing costs the retailer 8%(ish) of the total amount, which is how the lender makes their money.
So in your case, the retailer didn’t want to lose that much of their margin.
The interesting thing is that uber loses money on every ride. Waymo charges Uber more than Uber charges the customer.
On Uber’s side, though, this is preferable to losing the entire ride. Uber loses much more slowly by controlling the distribution and losing a few dollars per ride than by losing the entire customer base with no revenue from these customers.
Or, when you do have an accident it's typically more expensive to repair.
Does all of the event stuff and state stuff for you. Plus the orchestration.
One of the main differences is the DX — _how_ you define the agentic worklflows is far cleaner, so it's both faster to build and fast in production.
Each agent builds up state via tool use. On each loop of the network, you inspect this state to figure out which agent to run next. You don't build DAGs or create odd graphs — you write regular code in a router.
Or, more generally:
* Each agent has a specific goal within a larger network. Several agents each working on smaller goals means easier prompt generation, testing, iteration, and a higher success rate.
* The network combines agents to achieve an overall objective, with shared state modified by each agent
* The network’s router inspects state and determines which agent should run next
* The network runs in a loop, calling the router on each iteration until all goals are met
* Agents run with updated conversation history and state on each loop iteration
Realistically the challenge with agents has classically been: how can I build something reliable, and how can this run in production reliably? These patterns are largely what we've seen work.