و اما نظر شخصی خودم درباره این موضوع:
بچه‌ها، واقعیت اینه که Idempotency (تکرارپذیری) خیلی فراتر از یک بحث بک‌اِندی یا درگاه پرداخته؛ این یک «انتزاع» (Abstraction) هست که توی تمام لایه‌های مهندسی نرم‌افزار، از فرانت‌اِند گرفته تا زیرساخت، حضور داره.

۱. نگاه Idempotent در فرانت‌اِند
خیلی وقت‌ها ما ناخودآگاه کدهایی می‌زنیم که تکرارپذیر نیستن. مثلاً فرض کن یه دکمه داریم که قراره کاربر رو به مرحله بعد ببره:

حالت غلط (Non-Idempotent): setState(prev => prev + 1)
اینجا اگه کاربر به خاطر کندی سیستم یا از سر شیطنت ۱۰ بار روی دکمه کلیک کنه، استیت ما ۱۰ واحد می‌ره جلو! فاجعه‌ست، نه؟

حالت درست (Idempotent):
setState(2)
این یعنی کاربر اگه ۱۰۰ بار هم کلیک کنه، استیت همیشه روی عدد ۲ می‌مونه. خروجی پایداره.

یا مثلاً باز کردن یک مدال (Modal):

به جای اینکه بنویسیم setState(!state) که حالت Toggle داره و با هر کلیک یه جواب متفاوت می‌ده، باید بنویسیم setState(true). اینطوری همیشه خروجی همونه: مدال باز است.

۲. نگاه Idempotent در بک‌اِند و پیام‌رسانی
در لایه بک‌اِند هم داستان همینه. توی معماری‌های مبتنی بر ایونت (Event-Driven)، ممکنه یک پیام به هر دلیلی (مثل Retryهای مسیج‌بروکر) چند بار به دست مصرف‌کننده برسه.
سیستم نباید گیج بشه! باید همیشه یک Idempotency Key یا کلید یکتا همراه پیام باشه که حتی اگه ۳۰۰ بار هم پردازش شد، فقط بار اول «اثر» بذاره و دفعات بعدی صرفاً بگه: «انجام شده بود، خیالت راحت!»

ما به عنوان توسعه‌دهنده باید یاد بگیریم سیستم رو جوری طراحی کنیم که نسبت به «تکرار»، مقاوم (Resilient) باشه. فرقی نمی‌کنه کلیک کاربر باشه یا ریکوئستِ شبکه؛ سیستمِ بالغ، سیستمیه که Side-effect اضافه ایجاد نکنه.


@codehalics | کدهالیک