Engineering topic / Jeffrey Monica
Backend APIs, retries, and failure-aware design
Production APIs often fail in the space between a completed server mutation and a client that never receives a response. This collection explores those ambiguous states and how a system records its decisions.
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.
Articles and reference guides
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.
Try it yourself
Authentication state machineTrigger sign-in, expiry, refresh, revocation, and recovery. See permitted transitions and why recovery must not silently bypass step-up.API retry & idempotency labSimulate an operation that commits after a client timeout, then change retry counts and deduplication to compare server-side side effects.