cache پاسخ و داده خواندنی
IN-MEMORY DATA & QUEUESRedisCache، queue و state موقت
DEVNU / TECHNOLOGY / REDIS
Redis باید latency یا coordination را حل کند؛ نه اینکه صرفاً کنار PostgreSQL دیده شود.
Redis برای دادهای که باید خیلی سریع و اغلب موقت در دسترس باشد مناسب است: cache، counter، lock، queue metadata و session. اصل مهم این است که مشخص باشد با restart یا حذف key چه اتفاقی برای business data میافتد.
Redis در پروژه چه مسئولیتی دارد؟
در معماری DEVNU، Redis معمولاً مکمل PostgreSQL است. source of truth در database durable میماند و Redis برای کاهش read cost، هماهنگی jobها، rate limiting یا state کوتاهعمر استفاده میشود.
جایی که استفاده از آن باید یک مسئله مشخص را حل کند.
queue و job metadata
rate limiting
session و token state کوتاهعمر
distributed lock
counter و deduplication key
چه زمانی انتخابش میکنیم
read پرتکرار، queue، background job، rate limit، distributed lock و session کوتاهعمر use caseهای طبیعی هستند. TTL و namespace روشن کمک میکند state موقت به dependency مبهم تبدیل نشود.
چه زمانی انتخابش نمیکنیم
برای پروژهای با ترافیک پایین و query ساده، cache ممکن است invalidation complexity بیشتری از سود performance ایجاد کند. همچنین دادهای که از دسترفتنش غیرقابل قبول است نباید بدون persistence strategy فقط در Redis بماند.
استفاده از ابزار مهم نیست؛ نحوه نگهداری آن مهم است.
- 01TTL برای keyهای موقت
- 02prefix و namespace بر اساس domain
- 03cache invalidation صریح
- 04fallback وقتی Redis در دسترس نیست
- 05عدم ذخیره secret بدون نیاز
- 06memory limit و eviction policy آگاهانه
چند سؤال مهمتر از اسم stack هستند.
Cache-aside یا write-through؟
الگوی ساده cache-aside برای بسیاری از read pathها کافی است. write-through فقط وقتی consistency requirement و write path آن را توجیه کند اضافه میشود.
Redis یا database؟
اگر داده business truth است و relation/transaction دارد، database خانه اصلی آن است. Redis برای سرعت و coordination است، نه حذف مدل داده.
Queue داخل Redis؟
برای بسیاری از job queueها عملی و ساده است، اما retry، dead-letter behavior و idempotency باید در سطح application طراحی شوند.
پروژههایی که Redis در stack آنها ثبت شده است.
ربات تلگرام، Mini App و اتوماسیون سفارش
پاسارگارد؛ فروشگاه و پنل عملیاتی تلگرام
محصول شخصی برای جمعکردن ثبت سفارش، کیف پول، تحویل سرویس و مدیریت نمایندگان در یک جریان واحد داخل ربات و Mini App تلگرام.
- Telegram
- React
- TypeScript
- FastAPI
- PostgreSQL
- Redis
- Docker
- Nginx
07 / خدمات مرتبط
فناوری درون یک خروجی واقعی معنا پیدا میکند.
پرسشهای متداول درباره Redis
01آیا هر پروژه backend به Redis نیاز دارد؟+
خیر. تا وقتی bottleneck یا coordination use case روشن وجود ندارد، اضافهکردن Redis فقط یک سرویس دیگر برای نگهداری است.
02Redis جای PostgreSQL را میگیرد؟+
در معماریهای معمول DEVNU نه. Redis برای داده سریع و موقت است و PostgreSQL source of truth تراکنشی باقی میماند.
09 / NEXT STEP
اول مسئله را ببینیم، بعد stack را انتخاب کنیم.
اگر پروژه به این فناوری نیاز داشته باشد، دلیلش باید در معماری، عملکرد، تجربه کاربر یا هزینه نگهداری قابل توضیح باشد.
شرح پروژه