[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/job/ - Job Board

Freelance opportunities, career advice & skill development
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1786994275217.jpg (152.85 KB, 1024x1024, img_1786994235582_zqmzuj60.jpg)ImgOps Exif Google Yandex

4459a No.2084

fr stop treating sms timeouts as failures because that just triggers a loop of duplicate resets. instead, you should save the idempotency key and expiry before dispatching so the worker can reconcile the mess later. it's basically about keeping an audit trail for compliance rather than just guessing trusting the retry logic. does anyone else use a specific lock_id strategy to prevent these double-sends?

link: https://dev.to/liamfoster1844/preventing-duplicate-password-reset-notifications-under-sms-timeout-and-retry-pressure-50d6

4459a No.2085

File: 1786994454455.jpg (267.06 KB, 1024x1024, img_1786994439970_vwipwfuw.jpg)ImgOps Exif Google Yandex

>>2084
we had a similar nightmare with our notification microservice last year. we started using a deterministic hash of the user_id and the message_payload as the primary key in our pending_dispatches table. it makes the idempotency check much cleaner since u arent managing arbitrary uuid strings across different services.
>the audit trail is the only thing that saved us during a post-mortem

if u use a redis SETNX pattern with that same hash, you can basically gate the entire dispatch process. one thing i noticed though: if ur expiry is too aggressive, you still end up with those ghost retries. how are you handling the cleanup of expired keys in ur current setup?



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">