DataBase قواعد بيانات

حل “الطلبات المتزامنة المكررة” في Local-First: Request Coalescing (Single-flight) ✅ المشهد معروف: شاشة Product List تُرندر عدة منتجات في نفس اللحظة (Product A / B / C…) وكلهم يحتاجون نفس الـ Reference Data مثل: Get Section #4. بدون حل، كلهم يطلقون API Calls متطابقة قبل ما يكتمل أول طلب ويكتب للكاش. 🧠 الحل: SDK Request Coordinator (In-flight Map) نضيف طبقة داخل الـ SDK تعمل كـ “مُنسّق طلبات”: - تحتفظ بخريطة: Map<Key, Future> - المفتاح = (Section#4) - القيمة = Shared Future (طلب جاري) كيف يعمل؟ 1) أول طلب (Product A): - لا يجد المفتاح في الـ In-flight Map - ينشئ Shared Future - ويرسل 1x API Request فقط 2) الطلبات التالية (Product B / C…): - تجد Shared Future موجودة - لا تُنشئ طلبات جديدة - فقط “تنتظر” نفس الطلب الجاري (Await existing in-flight request) 📦 عند وصول النتيجة - يتم كتابة البيانات إلى Local DB (Cache) ✔️ - يتم توزيع نفس النتيجة فوراً لكل عناصر UI المنتظرة (Fan-out) ✔️ 📌 النتيجة - 1x Optimized API Request بدل 20x Duplicate Requests - Minimal Backend Load - Fast & Consistent UX - Cache يُملأ مرة واحدة ويُستخدم للجميع 🔎 مصطلحات مرتبطة - Request Coalescing - Single-flight Mechanism - In-flight Deduplication - Shared Future / Promise - (وأحياناً يُستخدم كـ Lock per Key) هل تطبّقون Single-flight في الـ SDK أو على مستوى Repository Layer؟ #API #MobileArchitecture #DistributedSystems