WHATS CRM HUB
تواصل معنا

البنية والتوسّع

نظام واحد، خمسة مستويات

النظام نفسه يخدم أوّل ٥ عملاء لك ويخدم لاحقاً ٥٬٠٠٠ عميل

لا تحتاج لإعادة كتابة أي شيء مع نموّ العمل. فقط انقل إلى خادم أكبر أو افصل المكوّنات. الـ hooks موجودة بالفعل في الكود.

من أكثر الأسئلة تكراراً من شركاء البيع المحتملين: "إذا بدأت صغيراً ونمت قاعدتي إلى آلاف العملاء، هل سيتحمل النظام؟". الجواب: نعم، دون إعادة كتابة. تعرض هذه الصفحة الطريق من Tier 1 (خادم Contabo بـ 4GB بسعر ‎SAR 50‎ شهرياً) حتى Tier 5 (Kubernetes متعدد المناطق).

جميع الأرقام أدناه مأخوذة من اختبارات حِمل داخلية حقيقية على الكود (راجع docs/system/LOAD_TEST.md، 1281 سطراً) — وليست تقديرات تسويقية. أسعار الخوادم هي أسعار 2026 العامة (Hetzner Cloud وContabo وAWS Singapore/Bahrain).

كيف تقدّر احتياجك

صيغة بسيطة لتقدير الذاكرة والقرص

قبل اختيار المستوى، احسب احتياجك بهذه القاعدة العامة.
~2 MB
ذاكرة لكل جهاز WhatsApp Web

العميل عادةً يستخدم 1-3 أجهزة WhatsApp. أي 100 عميل ≈ 100-300 جهاز ≈ 200-600 ميغابايت ذاكرة لجلسات whatsmeow فقط.

~1 KB
قرص لكل رسالة محفوظة

العميل يرسل/يستقبل 50-200 رسالة يومياً وسطياً. 100 عميل × 100 رسالة × 365 يوم ≈ 3.6 جيجابايت/سنة (قابل للأرشفة).

~80 KB
ذاكرة لكل اتصال WebSocket نشط

العميل عادةً يفتح 1-3 تبويبات. 100 عميل ≈ 200 اتصال WS نشط ≈ 16 ميغابايت ذاكرة.

~150 byte
ذاكرة لكل مهمة بثّ معلّقة

بثّ 100 ألف رسالة ≈ 15 ميغابايت حمولة Asynq queue. يناسب Tier 2 (6-8 جيجابايت ذاكرة) براحة.

قاعدة عامة: عميل نشط واحد ≈ 5-10 ميغابايت ذاكرة (whatsmeow + WS + buffer). 100 عميل = ~500 ميغابايت-1 جيجابايت ذاكرة لحالة العملاء. الباقي للنظام والـ Postgres والـ Redis والهامش.

مسار التوسّع — 5 مستويات

ابدأ رخيصاً، ارتقِ مع نموّ عملك

لا قيود مع المزوّد. لا إعادة كتابة. فقط انقل الخوادم أو أضف مكوّنات.
🌱
Tier 1

البداية (الشهر 1–3)

تجريب، عرض، قبل الإيراد
1–10 عملاء
حتى 10 آلاف رسالة/يوم
Cost
SAR 50–95 شهرياً
Spec
خادم واحد: 2 vCPU × 4 GB × 50 GB SSD
Providers
Contabo VPS S، Hetzner CX22، DigitalOcean Basic
Cocok untuk
موزّعون يبدؤون للتو، وكالات تختبر السوق، بيئة staging داخلية.
Highlights
  • كل المكوّنات على نفس الخادم (App + Worker + Postgres + Redis)
  • 4GB يكفي لأن حركة المرور قليلة والطابور فارغ
  • استثمار أوّلي أقل من SAR 100 — مخاطرة عمل ضئيلة
🌿
Tier 2

النموّ (الشهر 3–12)

أوّل عملاء يدفعون، رأس المال عاد
10–100 عميل
حتى 100 ألف رسالة/يوم
Cost
SAR 150–280 شهرياً
Spec
خادم واحد: 4 vCPU × 8 GB × 100 GB NVMe
Providers
Contabo VPS M، Hetzner CX32، DigitalOcean Premium
Cocok untuk
النقطة الذهبية لـ 80% من موزّعي SMB. يجب أن يكون رأس المال قد عاد بحلول الشهر 2-3 (10 عملاء × SAR 60 = SAR 600 إيراد).
Highlights
  • فقط ارفع DB_MAX_OPEN_CONNS=60، Asynq concurrency يبقى 50
  • ضبط Postgres: shared_buffers=2GB
  • آمن لحملات بثّ بـ 50 ألف تفصيل
  • نسخ احتياطي يومي تلقائي — حوالي SAR 20 إضافية للقطات
🌳
Tier 3

التوسّع (السنة 1–2)

تدفّق نقدي مستقرّ، جاهز للتوسّع
100–500 عميل
حتى 500 ألف رسالة/يوم
Cost
SAR 700–1٬170 شهرياً إجمالاً
Spec
4 خوادم: App (4×8GB) + Worker (4×8GB) + Postgres (4×16GB×200GB) + Redis (2×4GB)
Providers
Hetzner Cloud (Helsinki/Singapore)، AWS Lightsail، DigitalOcean
Cocok untuk
موزّعون كبار بعدد مستأجرين فرعيين كثير، أو مؤسسات متوسطة بتعدّد أقسام.
Highlights
  • Postgres على خادم منفصل (shared_buffers=4GB)
  • Redis مخصّص (queue + throttle + pubsub)
  • إعداد ops فقط — لا تعديلات على الكود
  • Postgres replica اختيارية للأحمال الثقيلة قراءةً
🏢
Tier 4

النطاق الكبير (السنة 2+)

مستوى مؤسسي، يحتاج HA + SRE
500–2٬000 عميل
حتى مليون رسالة/يوم
Cost
SAR 2٬800–4٬700 شهرياً إجمالاً
Spec
9 خوادم: App×2 (LB) + Worker×2 (sharded) + Postgres primary (8×32GB) + replica + Redis×2 + monitoring + PgBouncer
Providers
Hetzner Cloud، AWS Singapore/Bahrain، GCP
Cocok untuk
وكالات كبيرة، موزّعون بآلاف المستأجرين الفرعيين، علامات تجارية مؤسسية بفِرق عمليات.
Highlights
  • API stateless خلف Load Balancer — توفّر عالٍ
  • Worker مُجزّأ بنطاق hash لـ business_id
  • Postgres primary + replica (القراءة الثقيلة إلى replica)
  • حزمة مراقبة كاملة: Prometheus + Grafana + Loki
  • يحتاج SRE/devops واحدة على الأقل لتخطيط السعة المستمر
🏛️
Tier 5

مؤسسي / متعدد المناطق

عملاء عالميون، لوائح إقامة بيانات
2٬000+ عميل
5 ملايين+ رسالة/يوم
Cost
SAR 18٬750–56٬250 شهرياً حسب السحابة + المنطقة
Spec
Kubernetes (10–30 pod auto-scale) + Postgres مُدار + Redis مُدار + CDN + متعدد المناطق
Providers
AWS / GCP / Azure (Singapore، Bahrain، Riyadh، São Paulo)، Supabase Pro، Upstash
Cocok untuk
علامات عالمية، التزام لوائح صارم (PDPL السعودي لإقامة البيانات، LGPD البرازيل)، SaaS بعلامة بيضاء بمقياس SEA + الشرق الأوسط.
Highlights
  • Postgres مُدار (RDS / Neon / Supabase) — auto-failover، استرداد لحظي
  • Redis cluster mode (Elasticache / Upstash)
  • تثبيت المنطقة لكل مستأجر (التزام PDPL السعودي)
  • CDN للأصول الثابتة (CloudFront، Cloudflare)

ملاحظة: الأسعار أعلاه لا تشمل النطاق الترددي (عادةً 5–20 تيرابايت مجاناً عند Hetzner/Contabo) ولا التخزين الاحتياطي الخارجي.

ماذا يتولّاه النظام تلقائياً؟

لست بحاجة لتكون خبيراً — النظام هو الخبير

عدة مخاطر كلاسيكية في النطاق الكبير (طوابير جامحة، تجاوزات throttle، تسريب ذاكرة) معالجة تلقائياً.
حماية الطابور (حد أقصى 50٬000)

عند امتلاء طابور البثّ، يرفض النظام مهام جديدة برشاقة — لا انهيار، لا OOM. يحصل العملاء على رسائل خطأ واضحة.

Token Bucket لكل رقم (مضادّ Meta 429)

250 RPS لكل رقم، تلقائياً. لست بحاجة للقلق من حدّ المعدّل في Meta Graph API.

Heartbeat Lock (مضادّ تجاوز Throttle)

إذا فُقد قفل heartbeat (نسخة أخرى استلمت)، يُلغى الـ batch تلقائياً — لا إرسال مزدوج لنفس الجهاز قد يُسبّب حظر WhatsApp.

مهلة Statement 30 ثانية

الاستعلامات الطويلة تُلغى تلقائياً — لا goroutine يعلق إلى الأبد ولو وُجد استعلام سيّئ.

إغلاق رشيق

عند إعادة النشر، النظام يُجفّف الطلبات + يُغلق اتصالات WS بمهلة ثانية واحدة لكل عميل. لا تلف بيانات بسبب force-kill.

إعادة محاولة أُسية (Asynq)

فشلت مهمة؟ إعادة محاولة تلقائية بـ backoff ذكي. ترى فقط المهام التي يستحيل إكمالها.

النموّ = إعدادات، لا إعادة كتابة

ارتقِ المستوى دون لمس الكود

إليك ما يتغيّر عند الانتقال بين المستويات — كله على مستوى الإعدادات/التشغيل، وليس الكود المصدري.
حوض اتصالات قاعدة البيانات

Tier 1: DB_MAX_OPEN_CONNS=25. Tier 4: =120. فقط غيّر متغيّر البيئة وأعد التشغيل.

تزامن العمّال

Tier 1: concurrency=20. Tier 4: =200 لكل عامل × 2 عامل مُجزّأ. متغيّر بيئة فقط.

تجزئة العمّال

Tier 4 يبدأ باستخدام WORKER_SHARD_RANGE=0-50% و=50-100% على نسختين — تقسيم تلقائي بنطاق hash لـ business_id.

تقسيم Redis

Tier 4: queue، throttle، وpubsub يمكن استخدام نسختي Redis منفصلتين عبر REDIS_QUEUE_URL + REDIS_CACHE_URL — جاهز فعلاً.

Postgres Replica للقراءة

Tier 4: استعلامات القراءة الثقيلة يمكن توجيهها إلى replica عبر db.Pool.Read() — السقالة جاهزة، تفعيل اختياري لكل مستودع عند الحاجة.

فحص الصحة وإبطال الذاكرة المؤقتة

نقطة /health تفحص DB + Redis. إبطال ذاكرة مؤقتة بين النسخ عبر Redis pub-sub — يعمل بالفعل لنشر متعدد النسخ.

حائر في اختيار المستوى المناسب؟

تحدّث مع فريقنا 30 دقيقة — نساعدك في تحديد الحجم بناءً على عدد العملاء المستهدف وحجم الرسائل المقدّر وميزانية البنية التحتية.

استشارة حجم مجانية اسأل عبر WhatsApp