/w_600,c_scale,q_auto/v1695118159/posts/twitter_tmpl.png)
Part 3 of a REST API design series: pagination, HATEOAS, filtering and search, rate limiting, idempotency keys, and the practices that separate a demo API from a production one.
/w_600,c_scale,q_auto/v1695118159/posts/twitter_tmpl.png)
Part 2 of a REST API design series: naming resources so they don't need a manual, versioning without breaking clients, choosing an auth pattern, and structuring errors.
/w_600,c_scale,q_auto/v1695118159/posts/twitter_tmpl.png)
Part 1 of a REST API design series: what REST actually is, Fielding's six constraints, and the HTTP methods and status codes most APIs get subtly wrong.
Every outbox explanation assumes the broker is what breaks. Here is what actually happens when the database is the thing that goes away.
Rollback is a database primitive. Distributed systems don't have one, and treating compensation as if they did is how workflows quietly break.
Idempotency at rest is easy. Two retries arriving at the same moment is the case that breaks the version most teams wrote.
Your data disagreeing with itself isn't a bug. It's a trade-off. What eventual consistency guarantees, where you're already relying on it, and how to design for it instead of getting bitten by it.
A practical guide to designing long-running business processes with the Saga pattern - covering orchestration vs choreography, compensating transactions, timeouts, and observability.
Hi! Welcome to my blog
.NET, messaging, and distributed systems - the trade-offs the docs leave out.
Form not loading? Subscribe here.
See it on dometrain
See it on dometrain
See it on dometrain
See it on Amazon