ConcurrentBook: منصة وسائط عالية التزامن مع واجهة مستخدم تفاؤلية وآلية قفل التزامن (Mutex Locking)

هل سبق لك أن جربت الضغط على زر "حفظ" (bookmark) عشر مرات في ثانية واحدة لمجرّد معرفة ما إذا كان التطبيق سيتعطل أو يتباطأ؟ لقد قمت مؤخرًا ببناء منصة وسائط متكاملة (Full-Stack) صُممت للتعامل مع هذا النوع من الفوضى تحديدًا.

قمت بتطوير تطبيق ويب مخصص (باستخدام Next.js / Node.js) لعرض مقاطع الفيديو الدعائية وحفظها. لكن بدلاً من بناء واجهة عادية فقط، تعاملت مع تحديات حقيقية على مستوى الإنتاج: التزامن (concurrency)، والأمان الصارم، واختناقات الأداء في الواجهة الخلفية.

إليكم كيف صممت الحل:

? أمان الجلسات الصارم: طبقت تدفق مصادقة قوي باستخدام JWT مع Refresh Tokens وقاعدة "جلسة واحدة لكل جهاز"، وقمت بدمج Redis Cache لإدارة جلسات المستخدم النشطة فورًا، مما يخفف الضغط على قاعدة البيانات الأساسية من عمليات القراءة عالية التكرار.

⚡ التزامن و Mutex Locks: تؤدي التفاعلات السريعة من المستخدم غالبًا إلى حالات تنافس (race conditions) في الواجهة الخلفية. قمت بهندسة قفل (mutex lock) مخصص في الطرف الأمامي لضمان تحديثات حالة يمكن التنبؤ بها، مما قضى تمامًا على أي حالة تنافس أثناء عمليات الحفظ المتكررة والسريعة.

? تجربة مستخدم منخفضة الكمون (Low-Latency): قمت بدمج تحديثات الواجهة التفاؤلية (Optimistic UI) بحيث يبدو إجراء الحفظ فوريًا للمستخدم، إلى جانب تحسينات استراتيجية في الواجهة الأمامية لمنع أحمال العرض الثقيلة.

?️ تحسين الاستعلامات: تخلصت من الحمل الزائد غير الضروري لإنشاء كائنات MongoDB عن طريق استخدام دالة .lean() من Mongoose بشكل مكثف، مما قلل بشكل كبير من أوقات استجابة API.

? البنية التحتية باستخدام الحاويات: قمت بتجميع بنية الخدمات المتعددة بالكامل (الواجهة الأمامية، الخلفية، قاعدة البيانات، الذاكرة المخبئية) باستخدام Docker لضمان بيئة تطوير سلسة وقابلة للتوسع.