جميع المشاريع
corporate

تابتوك — توسيع منصة SaaS متعددة المستأجرين إلى أكثر من 100K معاملة شهرية على AWS

SaaS · متعدد المستأجرين · AWS · تجزئة قاعدة البيانات · TDD

العميل
Taptok for Business
الصناعة
SaaS / Digital Business Cards
الموقع
Gulf Region
السنة
2024
عرض الموقع الحي

100K+

Monthly transactions handled

on AWS infrastructure

0

Analytical query impact on tx DB

fully decoupled

sub-second

Transactional response time

under any report load

comprehensive

Test coverage (core paths)

TDD enforced

موجز المشروع
العميل
Taptok for Business
الصناعة
SaaS / Digital Business Cards
الموقع
Gulf Region
العمل
Web Development

كانت منصة بطاقات الأعمال الرقمية لتابتوك تقترب من حدود بنية قاعدة بيانات واحدة. كانت الاستعلامات التحليلية تتنافس مع الاستعلامات التعاملية، وكلاهما يتباطأ. بنينا تجزئة قاعدة البيانات القائمة على المستأجرين، وفصلنا التحليلات كليًا، وحافظنا على TDD طوال العملية — مما يجعل النظام المُعاد بناؤه آمنًا للتطوير المستمر.

01 / استعراض المشاريع

الحالة

توفر تابتوك بنية تحتية لبطاقات الأعمال الرقمية وإدارة جهات الاتصال للشركات الخليجية. كل حساب أعمال معزول تمامًا — جهات اتصاله الخاصة وأحداث المشاركة والتحليلات وبيانات الملف الشخصي. مع أكثر من 100K معاملة شهرية عبر آلاف المستأجرين، كانت بنية قاعدة البيانات الواحدة التي عملت عند الإطلاق تصبح الاختناق.\n\nالمشكلة المحددة كانت التنافس بين أنواع الاستعلامات. الاستعلامات التعاملية — إنشاء سجلات جهات الاتصال وتسجيل مشاركة بطاقة وتحديث بيانات الملف الشخصي — تحتاج إلى أن تكون سريعة ومتسقة. الاستعلامات التحليلية — تصدير التقارير والمجاميع والملخصات — ثقيلة ومقبول أن تكون متأخرة قليلًا. على قاعدة بيانات مشتركة، يمكن لاستعلام تحليلي طويل الأمد أن يحجب صفوفًا أو يستهلك I/O مما يبطئ العمليات التعاملية للمستخدمين النشطين.\n\nصممنا مخطط تجزئة قائم على المستأجرين. يتوزع المستأجرون عبر الشظايا استنادًا إلى استراتيجية تجزئة متسقة. التوجيه على مستوى التطبيق يوجه الاستعلامات إلى الشظية الصحيحة بشفافية — كود التطبيق لا يعرف أي شظية يتحدث إليها. إضافة سعة تعني إضافة شظية لا التوسع الرأسي لخادم واحد.\n\nفُصلت التحليلات تمامًا. تتدفق الأحداث إلى Redis، وتُجمِّعها وظائف الدُفعات بجدول، وتهبط النتائج في مخزن تقارير مخصص لا يكون أبدًا على مسار الاستعلام التعاملي. يرى المستخدمون النشطون استجابات تعاملية أقل من ثانية بغض النظر عن حمل التقارير.\n\nطُبِّق TDD طوال عملية إعادة البناء. كل فئة خدمة لديها تغطية اختبار قبل الشحن — يستطيع الفريق تغيير الأشياء بثقة.

02 / التحدي

ما كان يجب أن يتغير

كانت بنية قاعدة البيانات الواحدة تقترب من الطاقة الاستيعابية. الاستعلامات التحليلية الطويلة تنافست مع الاستعلامات التعاملية على I/O والأقفال — عاش المستخدمون النشطون تباطؤًا أثناء إنشاء التقارير. بدون تغطية اختبار، كان تعديل منطق المعاملات الجوهري محفوفًا بالمخاطر. التوسع الرأسي كان يصبح مكلفًا ومحدودًا.

03 / حلّنا

لقد تغيرت

تجزئة قائمة على المستأجرين مع توجيه تجزئة متسق — قابل للتوسع أفقيًا وشفاف على مستوى التطبيق. التحليلات مفصولة إلى أنبوب أحداث Redis ← تجميع خلفي ← مخزن تقارير. صفر تحميل استعلامات تحليلية على قاعدة البيانات التعاملية. TDD مُطبَّق طوال إعادة البناء — تغطية اختبار شاملة على جميع مسارات المعاملات الجوهرية.

04 / نتائج النواتج

ما حصل عليه العميل

  • 01 تجزئة أفقية — توسع بإضافة شظايا لا خوادم
  • 02 التحليلات مفصولة تمامًا عن قاعدة البيانات التعاملية
  • 03 بنية تحتية إنتاجية AWS (EC2, RDS, Docker)
  • 04 TDD طوال العملية — آمن للتغيير وآمن للشحن
أحضر القيد التالي

هل لديك مشروع يحتاج إلى طريقة أوضح للأمام؟

مناقشة المشروع