وقتی Redis به خواب می‌رود، صندوق ورودی کاربر تبدیل به میدان جنگ می‌شود!️

تصور کنید سیستم نوتیفیکیشن شما با سرعت بالا در حال ارسال پیامک‌ها و ایمیل‌های دوره‌ای است. برای اینکه به یک کاربر در بازه زمانی کوتاه پیام تکراری نفرستید (Deduplication & Suppression)، تصمیم می‌گیرید کلیدهای سایلنت را با یک TTL ساده داخل Redis ذخیره کنید.
همه چیز سریع، سبک و عالی به نظر می‌رسد… تا زمانی که:
رم ردیس پر می‌شود و کلیدها Evict می‌شوند.
سرویس به هر دلیلی ری‌استارت می‌شود یا با خطای 503 / Network Timeout مواجه می‌شوید.
یا یک Flush ناخواسته رخ می‌دهد.

نتیجه؟
تمام سد‌های دفاعی برداشته می‌شوند و صدها هزار پیامک یا ایمیل تکراری در عرض چند دقیقه روی سر کاربر آوار می‌شود؛ هم هزینه‌های زیرساخت سر به فلک می‌کشد و هم تجربه کاربری نابود می‌شود!

چرا اتکای ۱۰۰٪ به این‌مموری (In-Memory) خطرناک است؟
ردیس فوق‌العاده سریع است، اما ماهیت آن Ephemeral (فرّار) است. در سیستم‌های حساس به اسپم، شما نه تنها نیاز به سرعت دارید، بلکه به پایداری داده (Durability) و ردیابی (Auditability) نیاز دارید:
قابلیت اتکا و ماندگاری (Durability): دیتابیس تضمین می‌کند که سابقه و وضعیت سرکوب پیام‌ها (Suppression Policies) پایدار است و با کرش سرویس دود نمی‌شود و به هوا نمی‌رود.
ثبت وقایع و لاگ سایلنت‌ها (Audit Logs): وقتی پیامی ارسال نمی‌شود، باید دقیقاً مشخص باشد چرا، به چه دلیلی و طبق کدام Rule سرکوب شده است تا پشتیبانی و مانیتورینگ کور نمانند.

معماری برنده: ترکیب هوشمندانه دیتابیس و ردیس (Hybrid Pattern)
به جای حذف کامل ردیس یا تحمیل بار سنگین کوئری به دیتابیس، راهکار استاندارد پیاده‌سازی یک معماری ترکیبی و مقاوم است:
۱. دیتابیس به عنوان Source of Truth: سیاست‌های سایلنت، لاگ‌ها و وضعیت‌های ماندگار در RDBMS ذخیره و ایندکس‌گذاری دقیق می‌شوند.
۲. ردیس به عنوان Gatekeeper (سد دفاعی اول): ترافیک بالا در سطح میلی‌ثانیه با دستورات اتمیک مثل SET NX EX چک می‌شود.
۳. مکانیزم Fallback و تاب‌آوری: در صورت قطعی یا تایم‌اوت ردیس، با کمک Circuit Breaker و Local Cache (کش موقت درون سرویس) جلوی طوفان پیام‌های تکراری گرفته شده و سیستم به شکل کنترل‌شده با دیتابیس همگام می‌ماند (Graceful Degradation).

درس اصلی معماری سیستم:
در سرویس‌های حساس، هیچ‌وقت کلید جلوگیری از خسارت مالی یا اسپم کاربر را فقط در دست داده‌های فرّار قرار ندهید؛ سیستم باید برای لحظه وقوع خرابی (Design for Failure) طراحی شده باشد.

@DevTwitter | <AliReza Ghenaatiyan/>