I put this together after seeing the same gaps show up across fintech and high growth teams. Not gaps from bad engineers but gaps from moving fast and not having a good checklist moment before things go live. Use this before a major release, after an incident, or whenever someone asks "are we actually production-ready?" No sign-up. No call. Just the checklist.

☑ Idempotency & Retries

This is the one that bites fintech teams hardest. A user taps "pay" twice. A webhook fires twice. A job retries after a partial write. If your system isn't built for this, you're one network hiccup away from a support ticket that reads "I was charged twice."

Money Movement

• [ ] Payment and savings endpoints are idempotent. This means that the same request ID always produces the same result.
• [ ] Idempotency keys are validated server side and stored, not just forwarded
• [ ] Duplicate detection covers both sync API calls and async event consumers
• [ ] Partial failure is handled explicitly. No silent half-writes that leave accounts in a weird state

Job Processing

• [ ] Every job is safe to re-run without side effects
• [ ] Race conditions eliminated, pessimistic locks or atomic state transitions and NOT "it probably won't happen".
• [ ] Dead letter queues are monitored and alerted on, not just configured and forgotten.
• [ ] Failed jobs have a clear retry budget and a real terminal failure state (not infinite retry loops).
• [ ] Job throughput is tracked. You should always see any degradation before your users do.

Queues & Events

• [ ] At least, one delivery is handled at the consumer not assumed at the broker
• [ ] Event schema versioning exists before the first production publish (adding fields later is fine. Removing them silently is not)
• [ ] Consumer lag is monitored. A queue backing up at 2am should wake someone up