سال ها پیش هر بار که کاربر درخواست می‌فرستاد، سرویس احراز هویت باید توکن را بررسی می‌کرد، اطلاعات کاربر را از دیتابیس می‌خواند و مجوزهای دسترسی را محاسبه می‌کرد. وقتی تعداد درخواست‌ها زیاد می‌شد، همین بخش به یکی از گلوگاه‌های اصلی سیستم تبدیل می‌شد.

اینجاست که Cache وارد بازی می‌شود.

اگر اطلاعاتی مثل Session، Claims، Role یا نتیجه اعتبارسنجی Token را برای مدت کوتاهی Cache کنید، بخش بزرگی از درخواست‌ها دیگر نیازی به مراجعه به دیتابیس یا سرویس Identity ندارند. نتیجه کاملاً ملموس است:

✅ کاهش زمان پاسخگویی
✅ کاهش فشار روی دیتابیس
✅ افزایش توان پردازش سیستم
✅ تجربه کاربری بهتر

البته Cache در Authentication یک شمشیر دولبه است. اگر زمان انقضا (TTL) را درست انتخاب نکنید، ممکن است کاربری که دسترسی‌اش حذف شده، تا چند دقیقه همچنان بتواند از همان مجوزها استفاده کند.

به همین دلیل، طراحی Cache در Auth فقط برای افزایش سرعت نیست؛ باید بین Performance و Security تعادل برقرار کنید.

یک قانون ساده:
هر اطلاعاتی که امنیت بالایی دارد و ممکن است سریع تغییر کند، یا نباید Cache شود یا باید مدت نگهداری بسیار کوتاهی داشته باشد. یا در زمان ویرایش اطلاعات ، در Cache هم آپدیت شود.

سرعت مهم است، اما در سیستم‌های احراز هویت، امنیت همیشه اولویت اول است.

#Authentication #Authorization #Cache #Redis #Performance #Security #Backend #رادمان


🚀 Telegram: @devsourcech
🍂 Bale: @devsource