Designing a Passively Safe API
danealbaugh.com
Designing a Passively Safe API
1–10 of 29 posts
Re: Designing a Passively Safe API
#2> In APIs, passively safe means failures (crashes, timeouts, retries, partial outages) can't produce duplicate work, surprise side effects, or unrecoverable state.
I thought that was what 'idempotent' meant.
Re: Designing a Passively Safe API
#3> In APIs, passively safe means failures (crashes, timeouts, retries, partial outages) can't produce duplicate work, surprise side effects, or unrecoverable state. I thought that was what 'idempotent' meant.
It's mostly semantics. Passive safety is the "why" while idempotency is the "how".
Re: Designing a Passively Safe API
#4If anyone here wants to do this but don't want to implement all of this yourselves, this "field" is called Durable Execution. Frameworks such as Temporal, Restate and DBOS do a lot of the heavy lifting to get the idempotency, exactly once and recovery to a known state logic here.
Re: Designing a Passively Safe API
#5That sounds like a lot of over engineering and a good way to never complete the project. Perfect is the enemy of good.
Re: Designing a Passively Safe API
#6That sounds like a lot of over engineering and a good way to never complete the project. Perfect is the enemy of good.
Hmmm... depends on the project / phase of the project?
I am particularly not a fan of doing unnecessary work/over engineering, e.g. see https://charemza.name/blog/posts/agile/over-engineering/not-..., but even I think that sometimes things _are_ worth it
Re: Designing a Passively Safe API
#7That sounds like a lot of over engineering and a good way to never complete the project. Perfect is the enemy of good.
It sounds like a good way to make sure you don't overcharge your customers when handling such requests at scale. Failure and duplication will happen, and when serving enough requests will happen often enough to occupy engineering with investigation and resolution efforts forwarded from customer support.
Being prepared for these things to happen and having code in place to automatically prevent, recognize and resolve these errors will keep you, the customers and everyone in between sane and happy.
Re: Designing a Passively Safe API
#8> I'm in the process of migrating Augno's monolithic API to a microservices architecture.
Didn't we get to the point where we realized that microservices cause too much trouble down the road?
Re: Designing a Passively Safe API
#9From TFA “Making some tasks asynchronous”
I have bad news for everyone. Nothing in computing is synchronous. Every instance we pretend it’s not and call it something else you have a potential failure under the right circumstances.
The more your design admits this the safer it will be. There are practical limits to this which you have to determine for yourself.
Re: Designing a Passively Safe API
#10“Make the safe path the easiest path” is a great design principle. This should probably be a default mental model for public API design.