Skip to main content
ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

All topics

Engineering topic / Jeffrey Monica

Backend APIs, retries, and failure-aware design

A client times out, but the server might already have committed. I like digging into that uncomfortable middle ground: retries, idempotency, and how you find out what actually happened.

Key engineering considerations

Timeout ambiguity

A client timeout does not roll back a committed operation. Retries must be safe to repeat.

Authorization

Validate object-level access at every endpoint, not only at login or in UI state.

Diagnostics

Record decision reasons, trace IDs, and retry outcomes without logging tokens or personal payloads.

Field guides and review checklists

Articles and reference guides

Mobile voice agents: keep the backend in chargeHow I connected Swift and Kotlin clients to agent workflows, built Core ML and TensorFlow Lite integration boundaries, and kept authorization on the backend.Voice agents are distributed systems with microphonesBuilding an agent that talks is the easy demo. The harder work is authenticated tools, retries, evaluation, telemetry, CRM synchronization and the people who have to operate it.Retry storms: when resilience multiplies a failureRetry logic looks harmless in isolation. When a gateway, application service and SDK each apply their own retry policy, a single failed operation can multiply into a dependency outage. That interaction is the starting point for my retry-storm analysis.Idempotency under 100 competing requests: a reproducible in-process experimentI scheduled 100 calls against one in-process idempotency key. The side-effect callback ran once; a real crash or a second worker is still untested.Refresh-token rotation under concurrent replay: 200 scheduled callersI sent 200 scheduled refresh attempts through one local token family. Only one issued a successor; multiple workers would need a different test.Reproducing a one-time challenge replay race with 200 contendersI tried consuming one action-bound challenge 200 times. My single-process guard accepted one call and rejected 199; shared-store races remain untested.Android Play Integrity request binding and backend verdict policyWhat requestHash protects, what the server must verify, and why an integrity verdict is not a substitute for authorization.Authentication telemetry without leaking tokens or recovery secretsDesign privacy-conscious auth decision logs that help explain failures without recording the credentials that caused them.Idempotency when HTTP timeouts lie about server-side effectsA timeout does not undo a committed write. Model retries, duplicate operations and correctly scoped idempotency keys.Object-level API authorization: why a valid JWT is not enoughPractical tests for broken object-level authorization in authenticated mobile and backend APIs.Mobile session recovery as an explicit state machineModel sign-in, refresh rotation, expiry, step-up recovery, and revocation without creating a hidden authentication bypass.

Related case studies