كيف تبني نظام مزامنة بيانات بين فروع متعددة للمطاعم والمتاجر في لبنان والمنطقة

أكبر التحديات التقنية التي تواجه سلاسل المطاعم والمتاجر في لبنان والمنطقة العربية هي إدارة البيانات عبر فروع متعددة. كل فرع يعمل باستقلالية ويولد بياناته الخاصة: المبيعات، والمخزون، وبيانات العملاء. في نهاية اليوم أو في وقت حقيقي، يحتاج المكتب الرئيسي إلى رؤية موحدة لأداء جميع الفروع.

تحدي المزامنة في سلاسل المطاعم والمتاجر

المشكلة لا تقتصر على جمع البيانات من مكانين مختلفين. المشكلة الحقيقية تظهر في هذه السيناريوهات:

فرع في لبنان الشمالي يُسجل إرجاع منتج في نفس الوقت الذي يُعدِّل فيه المكتب الرئيسي سعر ذلك المنتج. أيهما الصواب؟

انقطع الإنترنت عن فرع بيروت لمدة 45 دقيقة أثناء وقت الذروة. ماذا يحدث للمبيعات المسجلة خلال تلك الفترة عند عودة الاتصال؟

موظف في فرع طرابلس غيّر سعر صنف بشكل يدوي دون أذونات كافية. كيف يتعامل النظام مع هذا التغيير عند مزامنته مع المركز؟

النموذج المركزي مقابل الموزع

هناك مقاربتان أساسيتان لبنية البيانات في سياق متعدد الفروع:

النموذج المركزي بالكامل: جميع الفروع تتصل بقاعدة بيانات واحدة في السحابة. كل عملية بيع أو تحديث مخزون يُكتب مباشرة في قاعدة البيانات المركزية. هذا النموذج بسيط لكنه يعتمد كلياً على استقرار الاتصال بالإنترنت. في لبنان، حيث تكون الشبكة غير مستقرة أحياناً، هذا النموذج محفوف بالمخاطر.

النموذج الهجين المحلي-المركزي: لكل فرع قاعدة بيانات محلية تعمل بشكل مستقل. البيانات تُزامن مع قاعدة البيانات المركزية في الوقت الفعلي عند توفر الاتصال، أو تُرسَل دفعياً عند عودته. لمعظم المطاعم والمتاجر في لبنان، النموذج الهجين هو الاختيار العملي.

تصميم آلية مزامنة البيانات

محور نظام المزامنة الموثوق هو تتبع كل تغيير كحدث مستقل بدلاً من مزامنة حالة الجدول بالكامل:

CREATE TABLE sync_events (
    id              uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    branch_id       bigint NOT NULL,
    event_type      text NOT NULL,
    entity_type     text NOT NULL,
    entity_id       bigint NOT NULL,
    payload         jsonb NOT NULL,
    occurred_at     timestamptz NOT NULL,
    synced_at       timestamptz,
    sync_status     text NOT NULL DEFAULT 'pending',
    idempotency_key text UNIQUE NOT NULL
);

هذا هو نهج Event Sourcing. كل تغيير موثق ومرتب زمنياً، مما يجعل حل التعارضات أمراً منطقياً.

حل التعارضات عند وجود تحديثات متزامنة

أكثر سيناريو تعارض شيوعاً هو تحديث المخزون من مصدرين مختلفين.

مثال: المخزون الحالي لصنف معين هو 100 وحدة. موظف في الفرع يسجل بيع 5 وحدات في نفس الوقت الذي يُعدّل فيه المكتب الرئيسي المخزون إلى 95 وحدة بعد جرد يدوي. النتيجة الصحيحة هي 90 وحدات.

الحل الصحيح يعتمد على العمليات الفارقة بدلاً من القيم المطلقة:

type InventoryEvent struct {
    ProductID  int64
    Delta      int    // موجب للإضافة، سالب للتخفيض
    Reason     string // 'sale', 'count_adjustment', 'receipt'
    OccurredAt time.Time
    BranchID   int64
}

func (s *SyncService) ApplyInventoryEvents(ctx context.Context, events []InventoryEvent) error {
    sort.Slice(events, func(i, j int) bool {
        return events[i].OccurredAt.Before(events[j].OccurredAt)
    })

    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    for _, event := range events {
        _, err = tx.ExecContext(ctx, `
            UPDATE inventory
            SET quantity = quantity + $1, updated_at = $2
            WHERE product_id = $3 AND location_id = $4
        `, event.Delta, event.OccurredAt, event.ProductID, event.BranchID)
        if err != nil {
            return err
        }
    }

    return tx.Commit()
}

bدلاً من كتابة "المخزون = 95"، يكتب الحدث "المخزون انخفض بمقدار 5". عند تطبيق الحدثين بالترتيب الزمني: انخفاض إلى 95 (التعديل)، ثم انخفاض 5 إضافية (البيع)، النتيجة 90. كلا التغييرين محفوظان.

إدارة انقطاع الشبكة

لكل فرع قائمة انتظار محلية للأحداث غير المُزامنة. عند انقطاع الاتصال، تستمر الأحداث في التسجيل محلياً. عند عودة الاتصال، يُرسل الفرع الأحداث المتراكمة مرتبة زمنياً للخادم المركزي.

عناصر مهمة في هذا النظام:

• كل حدث له معرف فريد (idempotency key) لضمان عدم معالجته مرتين
• يتتبع كل فرع آخر حدث تمت مزامنته للخادم المركزي
• الأحداث لا تُحذف بعد المزامنة بل تُحفظ كسجل تدقيق كامل

بناء لوحة تحكم المزامنة

المشرفون يحتاجون رؤية واضحة لحالة المزامنة عبر الفروع:

CREATE VIEW branch_sync_status AS
SELECT
    b.id AS branch_id,
    b.name AS branch_name,
    COUNT(*) FILTER (WHERE se.sync_status = 'pending') AS pending_events,
    COUNT(*) FILTER (WHERE se.sync_status = 'conflict') AS conflict_count,
    MAX(se.synced_at) AS last_synced_at,
    EXTRACT(EPOCH FROM (now() - MAX(se.synced_at))) / 60 AS minutes_since_sync
FROM branches b
LEFT JOIN sync_events se ON se.branch_id = b.id
GROUP BY b.id, b.name;

الدروس المستفادة من التطبيقات الحقيقية في لبنان

اختبر سيناريو الانقطاع قبل الإطلاق. أغلب فرق التطوير لا تختبر ماذا يحدث عند انقطاع الإنترنت لـ 30 دقيقة ثم عودته. هذا أكثر سيناريو مشكلة في البيئة اللبنانية. جرّبه عمداً في بيئة الاختبار قبل الانتقال للإنتاج.

لا تحاول مزامنة كل شيء في الوقت الفعلي. بعض البيانات لا تحتاج مزامنة فورية. بيانات المبيعات ضرورية، لكن إعدادات العرض وتكوين الشاشة يمكن مزامنتها ليلاً.

وفر لوحة تحكم للمزامنة مرئية للمشرفين. الأحداث غير المُزامنة والتعارضات المعلقة وآخر وقت مزامنة لكل فرع يجب أن تكون واضحة. هذه اللوحة تحوّل مشكلة تقنية خفية إلى مشكلة يمكن لفريق العمليات إدارتها دون تدخل الهندسة.