Stack Dispatch
Production-grade insights on AI systems, backend architecture, and security, written for senior engineers building at scale.
Latest dispatches
An alert should need two sightings and a fresh look
The rules our internal health page uses to decide when a failing check becomes an alert, and when the incident ends. All of it is one pure function with a table of tests.
An upsert that fails when nothing changed
A heartbeat that repeated the stored usage reading threw an error and skipped the alerts behind it. The repeat case needs its own test.
Wait for the lock, not the clock
How we stopped a race test from sleeping and hoping, by asking the database whether the second transaction was actually waiting.
A failed import stamped as done waits a day to be retried
Two small bugs in a scheduled importer: failures recorded as successes, and a lease released after the database had already gone.
Never spread a database row into a sign-in response
One spread operator was enough to hand every client the password reset token hash and the last login IP. The fix is small, and so is the lesson.
Make both payment references vouch for each other
A verified transaction proves that someone paid. It does not prove they paid for the thing you are about to mark as paid.
Keep read progress separate from dispatch acknowledgement
A reader position helps someone resume a log. An acknowledgement records who has accepted the work
Give a changing list a stable reading point
An API cursor should say what ordering and visibility it preserves while new records arrive
Put the operation key in the timeout response
A timeout can leave a remote command unresolved. Preserve the original operation identity so the caller can reconcile safely
A retry budget should name its final answer
A caller needs a useful outcome when the retry window closes, especially when the remote result is still uncertain
Return the first outcome when an idempotency key repeats
Duplicate suppression is only half the contract; callers also need a stable account of what the original request produced
An idempotency key can expire before its risk does
Retry safety depends on the lifetime of the original side effect, not only the convenience of a short deduplication window