Kafka vs AWS SQS for Fintech Retries: Three Recovery Boundaries to Weigh

A DEV Community article argues that for fintech reservations with fixed hold windows, the key design question is where the expiration decision is made and how failed attempts are recovered, not which queue retries fastest. It contends that a retry mechanism only redelivers work and cannot determine whether a state transition is still valid, so expiration should be driven by a stored deadline and guarded by idempotent, version-checked state changes. The piece compares Kafka's durable log with replay control, Amazon SQS's visibility-timeout redelivery, and RabbitMQ's direct acknowledgement and requeue semantics. It recommends treating the database as the authority on reservation state while the broker serves only as a delivery envelope, with recovery records that let operators inspect failures without reconstructing them from logs.