سیستم کش

نمای کلی

ویجنت از PostgreSQL به‌عنوان منبع حقیقت و Redis به‌عنوان لایه کش استفاده می‌کند. هدف کاهش latency و هزینه API برای درخواست‌های پربازدید است. تمام عملیات‌های کش «best-effort» هستند: اگر Redis قطع شود، درخواست‌ها از دیتابیس خوانده می‌شوند و چیزی block نمی‌شود.

چه چیزهایی کش می‌شوند؟

• کد OTP ورود — TTL کوتاه (دقیقه)، در Redis ذخیره می‌شود.
• شمارنده rate-limit (مثلاً ۲۰ پیام در دقیقه برای ویجت) — در Redis به‌صورت atomic.
• Embedding متن پرسش‌ها — TTL ۷ روز. وقتی کاربر سؤالی می‌پرسد که قبلاً embedding شده، بدون فراخوانی API از کش برمی‌گردد.
• پیکربندی عمومی ویجت (نام، رنگ، تم، موقعیت، فونت) — TTL ۶۰ ثانیه. هر پیام جدید این کانفیگ را می‌خواند.

روند کار کش ویجت

1. 1ویجت در مرورگر، /api/widget/{agentId} را GET می‌کند.
2. 2سرور، کلید widget:cfg:{agentId} را از Redis می‌خواند (~۱ms).
3. 3اگر Hit بود: کانفیگ برگردانده می‌شود.
4. 4اگر Miss بود: یک کوئری Prisma (۱۰–۳۰ms) اجرا و سپس در Redis با TTL ۶۰ ثانیه ذخیره می‌شود (write-back).
5. 5وقتی شما تنظیمات ویجت را در داشبورد ذخیره می‌کنید، کلید کش invalidate می‌شود تا بازدیدکنندگان جدید تنظیمات جدید را ببینند.

چرا از Postgres کش نمی‌گیریم؟

چون invalidation سخت می‌شود. ما به‌جای کش کردن کل ردیف‌های دیتابیس، فقط داده‌های امن و عمومی (مثل کانفیگ ویجت) را در یک ساختار مشخص کش می‌کنیم و invalidate را در همان‌جایی که write اتفاق می‌افتد (مثلاً web-widget-channel بعد از save) صدا می‌زنیم. این الگو «cache-aside» نام دارد و قابل‌اعتمادترین روش برای سیستم‌های چندنفره است.