REST API Design: The Constraints and HTTP Semantics Everyone Skips (Part 1 of 3)
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.
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.
How to keep Claude Code agents and skills out of shared repos using a dedicated config repo and symlinks.
What vector databases are, how they work, and when you actually need one - versus when pgvector is enough.
Hi! Welcome to my blog
.NET, messaging, and distributed systems - the trade-offs the docs leave out.
Form not loading? Subscribe here.