एक solo developer के रूप में surf forecast app चलाते समय हुए push notification duplicate भेजे जाने की घटना और उसके समाधान की प्रक्रिया का सारांश है।
यह एक आम feature है जिसमें खास conditions पूरी होने पर users को notification भेजा जाता है, लेकिन server को हर बार redeploy करने पर
“पहले ही भेजा गया notification” दोबारा चला जाता था।
■ समस्या
- हर redeploy/restart पर वही notification duplicate भेजा जा रहा था
- local में reproduce करना आसान नहीं था, और यह सिर्फ deployment के तुरंत बाद होता था, इसलिए root cause ढूँढना मुश्किल था
■ कारण
- duplicate रोकने (dedup) की state सिर्फ server memory में रखी गई थी
- redeploy पर process नया शुरू होता था और वह state पूरी तरह reset हो जाती थी → system इसे “नहीं भेजा गया” मानकर फिर भेज देता था
■ समाधान
- dedup key को boot के समय DB से फिर भरने (seed-on-boot) वाली structure में बदला → redeploy के बाद भी state बनी रही
- यह समस्या भी मिली कि ‘condition बदलने के क्षण पर ही notification’ वाला तरीका बीच में weight changes को miss कर देता था
→ reasons को accumulate करके चरणबद्ध तरीके से बढ़ाने (escalation) वाले तरीके पर shift किया - FCM token को 1 device, 1 token के principle से व्यवस्थित किया (token refresh और duplicate token handling सहित)
■ सीख
- notification dedup जैसी “सिर्फ एक बार होनी चाहिए” वाली state अगर केवल in-memory रखी जाए, तो deployment खुद bug बन जाता है
- state lifecycle को process के बजाय persistent storage के आधार पर design करना चाहिए
- trigger को ‘transition moment’ की जगह ‘current state’ के आधार पर judge करना कम चीजें miss करता है
server push/notification, cron·batch, और duplicate prevention logic पर काम करने वालों के लिए यह एक practical case study है।
अभी कोई टिप्पणी नहीं है.