انتقل للمحتوى
كل دراسات الحالة
منصة للرصد والتحليل الإعلامي ودعم القرارمدة القراءة: 11 دقيقة

Twiscope: الـ backend المشترك لمنصة رصد وتحليل إعلامي بتتوسع

Twiscope منصة بالعربي والإنجليزي للرصد والتحليل الإعلامي ودعم القرار. مجموعة المنتجات اللي بيعرضها الموقع الرسمي دلوقتي بتغطي تحليل الحسابات والمواضيع، وقياس تأثير المؤثرين، وتحليل التقارير بالـ AI، ورصد القنوات، ومجالات تانية. دراسة الحالة دي بتركّز على نطاق الـ backend المشترك اللي بنيته: pipelines تحليل X، و Decision Hub (Sadeed)، ومحرك التنبيهات، والاشتراكات والصلاحيات، وطبقة الـ edge للخدمات على AWS.

twiscope.netمطور الـ backend الوحيد (أكتوبر 2023 – أكتوبر 2025) · قائد فريق برمجيات من أغسطس 2024 · ASAS IT
نطاقات backend بتغطيها الدراسة
5
مصادر بيانات مربوطة
6
كمطور الـ backend الوحيد
سنتين
الـ gateway قدام 4 خدمات
Kong
المشكلة
نحوّل بيانات من مصادر مختلفة لتقارير ولوحات تدعم القرار، من غير ما طلبات المستخدم تتعطّل بسبب جمع البيانات وتحليلها.
دوري
بنيت الـ backend من البداية، وبعدها بنيت وبقيت بدير فريق بيوصل لـ 13 مهندس. مسؤول عن التوظيف وتقييم الأداء والتسليم، وبشارك بنفسي في تصميم الأنظمة والكود والتشغيل.
قرار هندسي مهم
ننفّذ الجمع والتحليل في مهام خلفية، ونعيد استخدام البيانات المجمّعة لنفس الفترة، ونتحقق من نسخ النتائج قبل نشر التحليل المدعوم بالـ AI.
النتيجة
سجلات الإنتاج أظهرت إن وقت عمليتين متقاربتين لجمع وتحليل حوالي 100 ألف منشور نزل من أكتر من 5 ساعات لحوالي 3 دقايق على نفس موارد السيرفر. التحسن شمل مسار المعالجة والـ caching، مش تحليل المشاعر وحده.

المشكلة

إيه المشكلة اللي كنا بنحلها؟

فرق التواصل والأبحاث في المنطقة محتاجة تفهم الكلام اللي بيدور حوالين كلمات مفتاحية وحسابات ومؤثرين وبراندات على X وشبكات تانية — بالعربي، مش بالإنجليزي بس. وأدوات الـ social listening العامة بتتعامل مع العربي بشكل ضعيف، ومش مناسبة لطريقة شغل الفرق دي.

نطاق الـ backend اللي بتغطيه الدراسة كان فيه خمسة أجزاء على منصة واحدة: تقارير معمّقة عند الطلب، ومتابعة المؤثرين لكل ربع سنة، ولوحات تحكم لدعم القرار بتقيّم البراند قصاد منافسينه، وتنبيهات مجدولة، وإشعارات — وكلهم بيعتمدوا على نفس آليات جمع البيانات والاشتراكات وصلاحيات المؤسسة.

القيود

إيه القيود اللي أثّرت على التصميم؟

  • الـ X API v2 عليه rate limits صارمة وتكلفة على كل request، فكل مسار لجمع البيانات لازم يبقى له budget و quotas.
  • الاشتراكات بتبقى لكل منتج ولكل منصة، وليها quotas يومية وشهرية، ومتشاركة على مستوى المؤسسة.
  • المؤسسات ليها أدوار (owner، admin، member، viewer) ولازم كل منتج يحترمها.
  • جمع البيانات وتحليلها ممكن ياخدوا دقايق؛ ومينفعش أي جزء منهم يعطّل أي request على الـ API.
  • لمدة سنتين كان الـ backend عليه مطور واحد، فكان لازم النظام يفضل بسيط كفاية عشان فريق صغير جدًا يقدر يشغّله.

الـ architecture

النظام متصمم إزاي؟

الـ requests بتدخل من Kong gateway بيتحقق من الـ JWTs وبيطبّق rate limiting، قبل ما يوجّهها لخدمة auth مكتوبة بـ FastAPI، والـ backend اللي على Django/DRF، وخدمة الـ realtime lookup، وخدمة Sanad AI. المهام اللي بتاخد وقت بتتنفّذ في Celery؛ و Elasticsearch فيه الـ snapshots وأحداث التنبيهات والـ news feed.

  1. الـ clients

    • تطبيق الويب

      تطبيق Angular فيه عرض 3D معمول بـ React (بناه زمايلي في الفريق؛ وأنا مسؤول عن الـ packaging والـ deployment بتوعه).

    • تطبيق Influencers Impact

      تطبيق موبايل بـ Flutter بناه زمايلي في الفريق على الـ APIs بتاعة الـ backend.

  2. الـ edge

    • Kong 3.8 ← AWS load balancer

      إعدادات declarative من غير قاعدة بيانات (DB-less): التحقق من الـ JWT بـ RS256، والـ rate limiting، والـ CORS، و portal موحّد لتوثيق الـ APIs.

    • خدمة الـ auth (FastAPI)

      بتطلّع access و refresh tokens بـ RS256؛ ومتوافقة مع الـ password hashes الموجودة في Django.

  3. الخدمات

    • الـ backend (Django/DRF)

      حوالي 25 app: Deep-In، Influencer Impact، Decision Hub، Alert System، الاشتراكات، المؤسسات.

    • خدمة الـ realtime lookup

      استعلامات live عند الطلب على X و TikTok و Instagram و Google.

    • Sanad AI

      مساعد retrieval-augmented؛ بيتبادل أحداث (events) التقارير والـ enrichment عن طريق SQS.

    • خدمة الإشعارات (FastAPI)

      إرسال push وإيميل، وليها Celery workers بتوعها.

  4. الـ async والبيانات

    • Celery + Beat

      Redis كـ broker؛ و queues للتقارير، و Decision Hub، والتقارير المجدولة، و backfills للـ sentiment.

    • PostgreSQL (RDS)

      البيانات الـ relational ونتايج التقارير.

    • Elasticsearch

      الـ snapshots بتاعة Decision Hub، وأحداث التنبيهات، والـ news feed، والـ word rollups، والـ logs.

    • SQS · S3

      أحداث report-ready و enrichment-done مع Sanad؛ وتخزين الميديا.

  5. البنية التحتية

    • Terraform على AWS

      VPC على availability zones اتنين، و Auto Scaling group و internal load balancer لكل خدمة، و GPU instance للـ AI inference.

    • الـ delivery

      GitHub Actions على self-hosted runners: بوابة أمان، restart، health check، bake للـ AMI، تحديث الـ launch template، و rollback.

    • الـ observability

      metrics لـ Django و Celery على Prometheus، و Elastic APM، والـ logs في Elasticsearch.

المنتجات

إيه المنتجات اللي بتدعمها المنصة؟

Deep-In

تقارير تحليل عند الطلب.

  • تقارير الكلمات المفتاحية على X عن طريق الـ full-archive search، مع enrichment للردود في حدود budget للـ requests في كل run.
  • تحليل الـ timeline والـ mentions لحسابات X.
  • إحصائيات مجمّعة (aggregates) للكلمات، والهاشتاجات، والإيموجي، والدول، وأهم الحسابات، والـ engagement، وكمان الـ sentiment من خدمة موديلات pretrained.
  • تقارير عند الطلب على Instagram و TikTok و Google للكلمات المفتاحية والهاشتاجات والحسابات.
  • لما معالجة التقرير بتخلص، بيتنشر event على SQS عشان Sanad AI يقدر يلخّص التقرير ويسترجع محتواه وقت الإجابة.

جمع البيانات بيشتغل لكل تقرير لوحده؛ الـ news feed بس هو اللي بيتسحب بشكل مستمر.

Influencer Impact

متابعة المؤثرين حسب الفئة وعلى مستوى كل ربع سنة.

  • فئات المؤثرين بيديرها الـ staff؛ ومتابعة فئة لمدة ربع سنة بتشغّل تحليل timeline لكل مؤثر فيها.
  • إحصائيات مجمّعة لكل فترة و word rollups في Elasticsearch بتغذّي ترتيب الفئات، وأهم الكلمات، والهاشتاجات، والإيموجي، والـ sentiment.
  • تحسين أداء لوحة التحكم واستقرارها (hardening): composite indexes اتعملت concurrently، و response cache على Redis لكل مستخدم، و burst throttle، و metrics للـ cache hit/miss.

X بس. وتطبيق الموبايل بناه زمايلي في الفريق.

Sadeed / Decision Hub

مراكز قرار (decision centres) بتقيّم البراند قصاد منافسينه.

  • مركز القرار فيه براند، وحسابات متابَعة، ومنافسين، وكلمات مفتاحية، وبيتحدّث كل ساعة، أو كل ست ساعات، أو كل يوم.
  • فيه dispatcher على Beat بيبدأ Celery chord واحد لكل مركز: جمع بيانات بالتوازي لكل entity، وبعدين callback واحد بيحسب الـ scores.
  • ستة مؤشرات deterministic بأوزان — السمعة، والرضا، والانتشار، والتأثير، والفرص، والمخاطر — والأوزان ليها versions لكل مستخدم أو بشكل global.
  • الـ snapshots في Elasticsearch، ومعزولة لكل tenant، هي اللي بيتعرض منها اتجاه التغيّر في المؤشرات ولوحات النتائج؛ والفترات الزمنية المتخزنة ممكن تتعالج من جديد ويتعاد حساب الـ scores بتاعتها.

بيدعم X بس، ولسه مفيش توقعات مستقبلية (forecasting).

Alert System

متابعة مجدولة مع ملخصات (digests) من غير تكرار.

  • كل تنبيه ليه Beat schedule خاص بيه (افتراضيًا كل 15 دقيقة، ومينفعش الفترة تقل عن 5 دقايق).
  • شروط بتتجمّع بـ AND على الكلمة المفتاحية، والـ mention، والـ sentiment، واللغة، والمكان، ومعاها شروط cooldown وحد أدنى لعدد الـ matches.
  • منع التكرار معمول بـ unique constraint في قاعدة البيانات لكل تنبيه و item؛ والأحداث بتتعمل لها index في Elasticsearch كمان، ولو الكتابة دي فشلت فيه command للإصلاح.
  • ملخص (digest) واحد لكل scan على الإيميل أو على HTTPS webhook؛ وعناوين الـ webhook لازم تعمل resolve لـ public IPs، والتحقق ده بيحصل وقت الحفظ ووقت الإرسال.

المحرك بيدعم X. والـ delivery at-least-once.

Notification System

إشعارات جوه التطبيق، و push، وعلى الإيميل.

  • سجلات إشعارات جوه التطبيق، والـ clients بتعمل لها polling.
  • إشعارات push عن طريق Firebase وإيميلات عن طريق SMTP، من خلال خدمة FastAPI ليها Celery workers بتوعها.
  • حالات pending و sent و failed؛ والـ retry بيحصل للأخطاء المؤقتة بس؛ و idempotency keys على Redis بتمنع الإرسال المكرر.

أغلبه بناه زمايلي في الفريق؛ وأنا عملت الـ scaffold بتاع الخدمة.

القرارات الهندسية

اخترنا إيه، وليه؟

  1. في الأول modular monolith، والخدمات المنفصلة للأجزاء اللي حدودها كانت واضحة

    بمطور backend واحد، المنتجات بدأت كـ Django apps بتتشارك الاشتراكات والصلاحيات والبيانات، وكل الشغل البطيء في Celery tasks. والأجزاء اللي حدودها واضحة ومستقلة — الـ authentication، والإشعارات، ومساعد الـ AI، والـ live lookups — اتفصلت في خدمات خاصة بيها ورا الـ gateway.

  2. طريقة واحدة لجمع البيانات، وتلات consumers

    جمع البيانات من X متنفّذ مرة واحدة، وبيتختار الوضع المناسب حسب الـ caller: التقارير بتحفظ النتايج في PostgreSQL، والتنبيهات بتجيب البيانات وتقيّمها من غير ما تحفظها، و Decision Hub بيجمع في حدود budget للـ reply enrichment. والتعامل مع الـ rate limits بيحترم الـ reset header بتاع X، وكـ fallback بيستخدم exponential backoff ليه حد أقصى.

  3. استخدام chords عشان الـ scores تبقى قابلة للمقارنة

    Decision Hub بيوزّع جمع البيانات بالتوازي على كل entity في المركز، وبيحسب الـ scores ليهم كلهم في callback واحد في نفس اللحظة، عشان البراند ومنافسينه يتقاسوا على نفس الـ window. وفيه lock لكل مركز بيمنع إن الـ runs تتداخل، وكل run بيتسجّل.

  4. حساب scores deterministic وقابل للتفسير

    المؤشرات عبارة عن معادلات بأوزان على مكوّنات normalized، زي نسبة الـ sentiment، والـ authority، والحجم (volume)، والـ engagement، والـ momentum. ولو فيه مكوّن مينفعش يتحسب، بيتعلّم عليه إنه غايب، والأوزان الباقية بيتعاد توزيعها (renormalize)، بدل ما يتحسب صفر من غير ما يبان.

  5. منع التكرار في قاعدة البيانات

    أحداث التنبيهات بتعتمد على unique constraint، وكل insert في savepoint خاص بيه، فالتكرار بيبقى no-op بتكلفة قليلة. والـ documents في Elasticsearch بتستخدم نفس الـ id بتاع قاعدة البيانات، وده بيخلّي إعادة الـ indexing idempotent.

  6. الـ authentication على الـ edge

    Kong بيتحقق من الـ RS256 tokens وبيطبّق الـ rate limits قبل ما الـ traffic يوصل لأي خدمة، والـ authentication اتنقل من الـ monolith لخدمة FastAPI بتطلّع الـ tokens، وفي نفس الوقت فضلت متوافقة مع الـ password hashes الموجودة.

المفاضلات

كسبنا إيه، وإيه اللي اتنازلنا عنه؟

الـ monolith بـ Celery workers مشتركة

سريع في البناء والتشغيل بمطور واحد؛ بس دلوقتي فيه worker container واحد بيسحب من كل الـ queues الأساسية، فلو زاد الحمل على queue واحدة، ممكن معالجة المهام في باقي الـ queues تتأخر.

تنبيهات مجدولة بدل الـ streaming

تكلفة متوقعة في حدود الـ limits بتاعة الـ X API، بس التنبيهات بتوصل في مواعيدها المجدولة (بالدقايق)، مش real time.

مؤشرات deterministic

قابلة للتفسير وثابتة، بس مفيش forecasting.

جمع البيانات عند الطلب

تكلفة الـ API بتتحسب بس لما حد يطلب تقرير؛ ومفيش أرشيف مستمر غير الـ news feed.

Elasticsearch على EC2 بنديره بنفسنا

تحكم كامل وتكلفة أقل، في مقابل إننا بنشغّل الـ backups والـ upgrades بنفسنا.

النتايج

وصلنا لإيه؟

تقليل وقت جمع البيانات وتحليلها

قُدت تحسينات في طريقة تنفيذ المهام والـ caching، قلّلت وقت عملية جمع وتحليل لحوالي 100,000 بوست من أكتر من خمس ساعات لحوالي تلات دقايق، على نفس موارد السيرفر. المقارنة لعمليتين متقاربتين، والتوقيتات من سجلات الـ production الداخلية. النتيجة بتشمل الـ caching وتحسينات مسار المعالجة كله، ومش قياس لسرعة تحليل المشاعر لوحده.

خمسة نطاقات backend، ومنصة واحدة

في النطاق اللي بتغطيه الدراسة، Deep-In، و Influencer Impact، و Decision Hub، و Alert System، والإشعارات، كلهم بيتشاركوا جمع البيانات والاشتراكات والصلاحيات والبنية التحتية.

ستة مصادر بيانات

X API v2، و EnsembleData لـ Instagram و TikTok، و Google Custom Search، و LinkedIn، و news feed بيتعمله index في Elasticsearch كل خمس دقايق.

طبقة edge مؤمَّنة للخدمات

كل request بيعدّي على التحقق من الـ JWT والـ rate limiting في الـ gateway؛ والخدمات موجودة في private subnets ورا internal load balancers.

deployments قابلة للتكرار

النشر على الـ production بيشتغل على self-hosted runner بعد نجاح بوابة فحص SAST/SCA على نفس الـ commit اللي هينزل. الـ workflow بيستخدم الـ commit ده، وبياخد نسخة احتياطية، ويعيد تشغيل الخدمة، ويتحقق من سلامتها، ويحدّث الـ machine image، مع rollback لو النشر فشل. وفيه فحوصات أمان إضافية على بيئة ما قبل الإنتاج.

دوري

  • كنت مطور الـ backend الوحيد من أكتوبر 2023 لحد أكتوبر 2025، وتولّيت قيادة الفريق في أغسطس 2024 بالتوازي مع دوري في الـ backend؛ ولسه أكبر مساهم (حوالي 70% من commits الـ backend في المجمل).
  • بنيت الـ pipelines بتاعة تحليل X، والـ clients المشتركة لـ X و Instagram و TikTok و Google.
  • بنيت Decision Hub (Sadeed) من أوله لآخره، والمحرك بتاع الـ Alert System؛ وزميل في الفريق بنى أغلب الـ tasks بتاعة توصيل التنبيهات.
  • بنيت الـ backend بتاع متابعة المؤثرين، والاشتراكات والـ quotas، والـ JWT authentication، وأدوار المؤسسات.
  • بنيت إعدادات الـ Kong gateway، وخدمة الـ auth بـ FastAPI، وخدمة الـ realtime lookup، والبنية التحتية بـ Terraform، والـ monitoring stack. وصممت وشغّلت workflows للنشر على GitHub Actions باستخدام self-hosted runners وبوابات أمان بتفحص نفس الـ commit اللي هينزل.
  • زمايلي في الفريق بنوا الـ frontends بتاعة الويب والموبايل، وأغلب خدمة الإشعارات، والتقارير المجدولة، وتصدير الملفات، والـ ingestion بتاع LinkedIn والأخبار.

حدود الشغل

  • مقارنة الوقت لحوالي 100,000 بوست مبنية على سجلات production داخلية، والنتيجة مذكورة بناءً على متابعتي للشغل. حالة الـ cache ونسبة البيانات اللي اتاخدت منه مش منشورين، فالمقارنة مش اختبار بـ cache فاضي ولا ضمان لأداء المنصة كلها. مفيش هنا نسبة معلنة لتوافر الخدمة.
  • مفيش WebSocket ولا push channel: التنبيهات بتشتغل بمواعيد مجدولة، وخدمة الـ realtime بترد على الـ live lookups لما تتطلب.
  • الـ sentiment جاي من موديلات pretrained من Hugging Face، بتشغّلها خدمة منفصلة؛ ومفيش أي موديل بيتدرّب في المنصة دي.
  • الـ repositories فيها test suites كبيرة (حوالي 3,300 test function). بوابة الأمان شرط إلزامي للنشر وبتفحص نفس الـ commit اللي هينزل. اختبارات التطبيق جزء من التحقق قبل الإصدار، من غير ادعاء إن كل مجموعات الاختبارات بتمنع النشر تلقائيًا.
  • Twiscope منتج من منتجات ASAS IT؛ ودراسة الحالة دي بتقتصر على شرح الـ architecture، من غير عرض الإعدادات الداخلية.
  • مجموعة منتجات Twiscope المعروضة للناس اتطورت بعد نطاقات الـ backend الخمسة اللي بتغطيها الدراسة؛ والموقع الرسمي twiscope.net هو المرجع لأسماء المنتجات المتاحة دلوقتي وحالتها.
Django / DRFCeleryRedisPostgreSQLElasticsearchKongFastAPIAWSTerraform

دراسة الحالة اللي بعدها

Sanad AI

مساعد Twiscope بيجاوب على أسئلة عن تقارير التحليلات بالعربي والإنجليزي، وبيوضّح مصادر الإجابة. قُدت تصميم النظام واستراتيجية البحث والـ prompts مع مهندسي الـ AI اللي نفّذوا مكوّنات البحث. شغلي العملي شمل تأسيس الخدمة، وتجهيز التقارير للبحث، وربط الـ APIs، والنشر والتتبّع.

اقرأها