أنواع الإشعارات ومين بيوصلها
iOS → APNsAndroid → FCMSMS → TwilioEmail → SendGrid
أول ما اليوزر يسطّب الأبلكيشن أو يسجّل، بنجمع device token والموبايل والإيميل ونخزنهم.
من الديزاين البسيط للمحنّك
سيرفر إشعارات واحد: SPOF، صعب يكبر، وأي بطء من APNs أو غيره بيعطل كل حاجة.
Services
Notification Serversauth + validation
Queue لكل نوع
Workers
APNs / FCM / SMS / Email
الـ DB والكاش بيشيلوا بيانات اليوزر والجهاز والـ templates. الـ queues بتفصل الأنواع عن بعض: لو الـ SMS بايظ، الإيميل يكمل عادي.
التفاصيل المهمة
| الموضوع | الفكرة |
|---|---|
| Reliability | احفظ الإشعار في notification log عشان تعيد لو فشل. الـ exactly-once صعب، فاستخدم dedupe بالـ event ID |
| Templates | قوالب جاهزة بتوحّد الشكل وتقلل الغلط |
| Settings | اليوزر يختار يستقبل إيه وعلى أنهي قناة (opt-in) |
| Rate limiting | متغرّقش اليوزر، وإلا هيقفل الإشعارات خالص |
| Retry | فشل؟ يرجع للطابور. لو اتكرر الفشل، نبعت alert للمطورين |
| Security | appKey و appSecret عشان الـ clients الموثوقين بس هم اللي يبعتوا |
| Monitoring | راقب عدد الرسايل في الطابور (لو كبر، زوّد workers)، وتابع open rate و click rate |
Checklist الإشعارات
🧠 اختبر نفسك
١) ليه طابور لكل قناة مش طابور واحد؟
عشان بطء أو عطل قناة (زي SMS) مايوقفش الإيميل والـ push.
٢) exactly-once صعب. البديل العملي إيه؟
notification log + dedupe بالـ event ID عشان الإشعار ميتبعتش مرتين.
٣) ليه rate limit على الإشعارات مش بس على الـ API؟
لو غرّقت اليوزر هيقفل الإشعارات خالص، وخسرت القناة.
٤) الطابور كبر فجأة. أول حاجة تعملها؟
زوّد workers، وتابع ليه المزوّد (APNs أو Twilio) بقى بطيء.