Channel: DevGuide 🇵🇸
مفهوم الـ Cache Invalidation 🔥
.
.
تعال أحكيلك حكاية صغيرة:
أنت فتحت تطبيق لطلب الأكل، لقيت العرض بيقولك "خصم 50% على أول أوردر".. فرحت ودخلت على البرجر، ولسه بتختار، التطبيق قالك "الخصم خلص" 🫠
طب ما أنت لسه قايل من 5 ثواني إن فيه خصم!
هنا بقى ييجي دور الـ "Cache Invalidation"!
———
📌 يعني إيه Cache أصلًا؟
ببساطة كده، الكاش ده زي لما بتصور شاشة المحادثة بدل ما ترجع تقراها كل مرة، أو زي لما المطعم بيطبع منيو مخصوص ويحطه قدام الناس بدل ما يطبع كل مرة حد يسأله عن المنيو.
هو نسخة سريعة من البيانات، بتخلي الموقع أو التطبيق أسرع، بدل ما يروح يجيب الداتا من السيرفر كل مرة.
بس السؤال هنا:
إمتى نرمي الصورة القديمة ونجيب واحدة جديدة؟
———
📌 ليه بنعمل Invalidate للكاش؟
"لأن البيانات بتتغير"
مثلًا:
- السعر تغير
- البوست اتعدل
- المنتج خلص من المخزن
لو الكاش فضل يعرضلك بيانات قديمة، ده هيبقى تضليل، وهيخلي تجربة المستخدم في الضياع.
تخيل تفتح فيسبوك تلاقي بوستات من أسبوعين فوق، أو تدخل تشتري موبايل تلاقيه "متاح"، ولما تضيفه للسلة يقولك "غير موجود"
يبقى لازم نعرف إمتى نرمي الكاش ونرجع نجيب الداتا الجديدة.
———
💡 أنواع الـ Cache Invalidation
1- الـ Time-based Invalidation
يعني الكاش يبقى له "صلاحية".
مثلًا: "احفظ البيانات دي لمدة 5 دقائق، وبعدها امسحها".
ده مفيد في الداتا اللي مش بتتغير بسرعة، زي صفحة البروفايل.
2- الـ Event-based Invalidation
ده بقى لما يحصل "حاجة معينة"، نمسح الكاش فورًا.
زي مثلًا الأدمن يعدل سعر منتج، أو المستخدم يضيف بوست جديد وقتها هنرمي الكاش القديم.
———
🤔 نستخدم أي نوع؟
- لو الداتا بتتغير بسرعة جدًا يبقى الـ Event-based
- لو الداتا ثابتة نسبيًا وعايز توازن بين الأداء والدقة يبقى الـ Time-based
وأحيانًا بنستخدم الاتنين مع بعض...
———
⚠️ تحديات الـ Cache Invalidation
- بيانات قديمة بتظهر
لو الكاش متمسحش في الوقت الصح، المستخدم هيشوف داتا غلط وده هيخلي الثقة أقل والمشاكل هتزيد.
- ضغط زائد على السيرفر
لو مسحت الكاش كتير أو بدري، السيرفر هيتخنق منك وهيبقى بطيء.
🎯 الحل؟
- استخدم أدوات قوية زي Redis أو Memcached
- اعمل Monitoring للكاش بتاعك
- اختبر الـ Invalidation كويس جدًا
- قسم الكاش حسب نوع الداتا، مينفعش كله يتعامل بنفس الطريقة
———
✅ أمثلة من أرض الواقع
- مواقع التجارة الإلكترونية
زي Amazon أو Noon، بيستخدموا Event-based Invalidation لما السعر أو المخزون يتغير، وTime-based لحاجات زي صفحات التصنيفات.
- السوشيال ميديا
تطبيق Facebook مثلاً بيخزن كاش للبوستات بس أول ما حد يعدل البوست أو يعمل كومنت الـ Event-based triggers تمسح الكاش وتجيب الجديد فورًا.
———
وفقكم الله لكل خير 🌿
.
.
تعال أحكيلك حكاية صغيرة:
أنت فتحت تطبيق لطلب الأكل، لقيت العرض بيقولك "خصم 50% على أول أوردر".. فرحت ودخلت على البرجر، ولسه بتختار، التطبيق قالك "الخصم خلص" 🫠
طب ما أنت لسه قايل من 5 ثواني إن فيه خصم!
هنا بقى ييجي دور الـ "Cache Invalidation"!
———
📌 يعني إيه Cache أصلًا؟
ببساطة كده، الكاش ده زي لما بتصور شاشة المحادثة بدل ما ترجع تقراها كل مرة، أو زي لما المطعم بيطبع منيو مخصوص ويحطه قدام الناس بدل ما يطبع كل مرة حد يسأله عن المنيو.
هو نسخة سريعة من البيانات، بتخلي الموقع أو التطبيق أسرع، بدل ما يروح يجيب الداتا من السيرفر كل مرة.
بس السؤال هنا:
إمتى نرمي الصورة القديمة ونجيب واحدة جديدة؟
———
📌 ليه بنعمل Invalidate للكاش؟
"لأن البيانات بتتغير"
مثلًا:
- السعر تغير
- البوست اتعدل
- المنتج خلص من المخزن
لو الكاش فضل يعرضلك بيانات قديمة، ده هيبقى تضليل، وهيخلي تجربة المستخدم في الضياع.
تخيل تفتح فيسبوك تلاقي بوستات من أسبوعين فوق، أو تدخل تشتري موبايل تلاقيه "متاح"، ولما تضيفه للسلة يقولك "غير موجود"
يبقى لازم نعرف إمتى نرمي الكاش ونرجع نجيب الداتا الجديدة.
———
💡 أنواع الـ Cache Invalidation
1- الـ Time-based Invalidation
يعني الكاش يبقى له "صلاحية".
مثلًا: "احفظ البيانات دي لمدة 5 دقائق، وبعدها امسحها".
ده مفيد في الداتا اللي مش بتتغير بسرعة، زي صفحة البروفايل.
2- الـ Event-based Invalidation
ده بقى لما يحصل "حاجة معينة"، نمسح الكاش فورًا.
زي مثلًا الأدمن يعدل سعر منتج، أو المستخدم يضيف بوست جديد وقتها هنرمي الكاش القديم.
———
🤔 نستخدم أي نوع؟
- لو الداتا بتتغير بسرعة جدًا يبقى الـ Event-based
- لو الداتا ثابتة نسبيًا وعايز توازن بين الأداء والدقة يبقى الـ Time-based
وأحيانًا بنستخدم الاتنين مع بعض...
———
⚠️ تحديات الـ Cache Invalidation
- بيانات قديمة بتظهر
لو الكاش متمسحش في الوقت الصح، المستخدم هيشوف داتا غلط وده هيخلي الثقة أقل والمشاكل هتزيد.
- ضغط زائد على السيرفر
لو مسحت الكاش كتير أو بدري، السيرفر هيتخنق منك وهيبقى بطيء.
🎯 الحل؟
- استخدم أدوات قوية زي Redis أو Memcached
- اعمل Monitoring للكاش بتاعك
- اختبر الـ Invalidation كويس جدًا
- قسم الكاش حسب نوع الداتا، مينفعش كله يتعامل بنفس الطريقة
———
✅ أمثلة من أرض الواقع
- مواقع التجارة الإلكترونية
زي Amazon أو Noon، بيستخدموا Event-based Invalidation لما السعر أو المخزون يتغير، وTime-based لحاجات زي صفحات التصنيفات.
- السوشيال ميديا
تطبيق Facebook مثلاً بيخزن كاش للبوستات بس أول ما حد يعدل البوست أو يعمل كومنت الـ Event-based triggers تمسح الكاش وتجيب الجديد فورًا.
———
وفقكم الله لكل خير 🌿
إزاي تعمل Rate Limiting في Node.js؟ 🤔
.
.
لو أنت شغال Backend بـ Node.js، أكيد في يوم من الأيام جالك requests كتير جدًا في نفس اللحظة – سواء من مستخدم بيجرب DDOS، أو من Bots، أو حتى من عميل بيعمل Load Test بالغلط – وفجأة الـ Server بيضرب وبيقع أو يبدأ يرد بـ 429 Too Many Requests.
في الموقف ده الحل هو إنك تعمل Rate Limiting...
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_node-nodejs-javascriptdeveloper-activity-7344642463216586753-xq1v
🔗 Facebook:
https://www.facebook.com/share/p/1GEvu5DzAT
🔗 Qabilah:
https://qabilah.com/posts/gCddARMqyDI
.
.
لو أنت شغال Backend بـ Node.js، أكيد في يوم من الأيام جالك requests كتير جدًا في نفس اللحظة – سواء من مستخدم بيجرب DDOS، أو من Bots، أو حتى من عميل بيعمل Load Test بالغلط – وفجأة الـ Server بيضرب وبيقع أو يبدأ يرد بـ 429 Too Many Requests.
في الموقف ده الحل هو إنك تعمل Rate Limiting...
———
🔗 LinkedIn:
https://www.linkedin.com/posts/mentoor-io_node-nodejs-javascriptdeveloper-activity-7344642463216586753-xq1v
🔗 Facebook:
https://www.facebook.com/share/p/1GEvu5DzAT
🔗 Qabilah:
https://qabilah.com/posts/gCddARMqyDI
HTML Embed Code: