AWS SAA 13 - Building Decoupled Architectures

🎯 Building Decoupled Architectures — بناء بنى مفصولة

في عالم تطبيقات اليوم، لم يعد بناء نظام واحد كبير يضم كل الوظائف خياراً قابلاً للتطبيق. عندما يزداد الضغط أو يحدث عطل، ينهار النظام بأكمله وكأن شيئاً لم يكن. هنا يأتي دور Decoupled Architectures — فلسفة تصميم تفصل المكونات عن بعضها لتجعلها تعمل وتفشل وتتوسع باستقلالية. في هذه الوحدة سنتعرف على مفهوم الفصل (Decoupling) وخدمات AWS الأساسية لتحقيقه: Amazon SQS للطوابير، Amazon SNS للإشعارات، وAmazon MQ للبيئات الهجينة — وكيف يمكن لهذه الأدوات أن تحوّل تطبيقك الهش إلى نظام مرن لا يتأثر بفشل أي جزء منه.

1️⃣ Tight Coupling in a Three-Tier Architecture — الاقتران المتماسك في البنية ثلاثية الطبقات

📖 الاقتران المتماسك (Tight coupling) يعني أن المكونات في النظام تعتمد على بعضها البعض لدرجة أن فشل أحدها يؤدي إلى فشل النظام بأكمله.
في البنية ثلاثية الطبقات (Three-tier architecture)، تتواصل طبقات الويب والتطبيق وقاعدة البيانات بطريقة متزامنة (Synchronous)، حيث يرسل المصدر طلباً وينتظر الرد قبل المتابعة. إذا تعطل خادم التطبيق أو خادم الويب، يتوقف النظام بالكامل وتظهر الأخطاء للعميل مباشرة.

📋 تحديات الاقتران المتماسك:

• فشل خادم التطبيق أو الويب يؤدي إلى توقف النظام بالكامل وعودة أخطاء للعميل.
• تحديث خادم التطبيق للصيانة أو إصلاح علّة يتطلب إيقاف النظام بأكمله عن العمل.
• توسيع أي طبقة يتطلب تحديث الكود يدوياً ليعرف عناوين IP الجديدة ومتى يوجّه الحركة لكل منها.

شركة نقلت تطبيقها الداخلي إلى AWS ببنية ثلاثية الطبقات تستخدم Amazon RDS لقاعدة البيانات وAmazon EC2 لخوادم الويب والتطبيق.
تواصل الطبقات متزامن — خادم الويب يرسل طلباً لخادم التطبيق وينتظر الرد.
عندما تعطل خادم التطبيق، توقف الموقع بالكامل وعادت الأخطاء للعملاء.
قضى فريق التشغيل ساعات في إعادة التوجيه يدوياً.

2️⃣ Tight Coupling Increases Scaling Complexity — الاقتران المتماسك يزيد تعقيد التوسع

📖 كلما زاد ارتباط المكونات، زادت صعوبة توسيع النظام — فإضافة مكون جديد يتطلب تحديث توصيلات متعددة في الكود.
عندما ترتبط المكونات مباشرة، يصبح التوسع الأفقي (Scaling out) عملية معقدة: كل خادم جديد يحتاج إلى معرفة بجميع الخوادم الأخرى وتحديث الإعدادات في كل طبقة.

📋 مشاكل توسيع البنى المتماسكة:

• إضافة خادم ويب جديد يعني تحديث إعدادات الاتصال مع جميع خوادم التطبيق.
• إضافة خادم تطبيق يتطلب تحديث جميع خوادم الويب لتعرف الخادم الجديد.
• فشل خادم تطبيق واحد يجعل خوادم الويب المرتبطة به ترسل طلبات إلى خادم معطل دون أن تدري.

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

3️⃣ Decoupling Between Layers — الفصل بين الطبقات

📖 على مستوى البنية التحتية، أفضل طريقة للفصل بين الطبقات هي إدخال وسيط يدير الاتصالات نيابة عن المكونات — مثل موازن الأحمال Elastic Load Balancing (ELB).
في التصميم المفصول (Loose coupling)، نستخدم حلولاً مُدارة كوسيط بين طبقات النظام. هذا الوسيط يتولى اكتشاف الأعطال وتوزيع الحركة والتوسع تلقائياً دون تدخل يدوي.

📋 كيف يحقق ELB الفصل بين الطبقات:

• إضافة خادم ويب جديد يحتاج فقط توصيلتين — واحدة لكل موازن — بدلاً من عشرات التوصيلات المباشرة.
• عند فشل خادم تطبيق، يكتشفه موازن الأحمال تلقائياً ويتوقف عن توجيه الحركة إليه.
• جميع خوادم الويب تظل تعمل بشكل طبيعي دون أي تعديل في الكود أو الإعدادات.

نفس الشركة السابقة طبقت الحل—وضعت ALB (Application Load Balancer) أمام خوادم الويب.
وضعت ALB آخر بين طبقة الويب وطبقة التطبيق.
النتيجة: إضافة خادم ويب جديد أصبحت تحتاج فقط توصيلتين بدلاً من عشرات.
عند تعطل خادم تطبيق، اكتشفه ALB عبر فحوصات الصحة وتوقف عن إرسال الحركة إليه فوراً.
كل شيء تم تلقائياً دون أي تدخل يدوي.

4️⃣ Tight Coupling Within the Application — الاقتران المتماسك داخل التطبيق

📖 التماسك لا يحدث فقط بين الطبقات — بل يحدث أيضاً داخل التطبيق نفسه عندما تُجمع كل الوظائف في وحدة برمجية واحدة تُسمى التطبيق المتجانس (Monolithic application).
في التطبيقات المتجانسة، كل الوظائف — من معالجة الدفع إلى تحويل الصور إلى إدارة الحسابات — تعمل ضمن عملية واحدة. إذا استهلكت وظيفة ما موارد كثيرة، تتأثر جميع الوظائف الأخرى. وإذا تعطلت وظيفة واحدة، يتوقف التطبيق بأكمله.

📋 تحديات التطبيق المتجانس:

• تباطؤ وظيفة واحدة (مثل تحويل الصور) يؤدي إلى بطء جميع الوظائف الأخرى.
• تعطل وظيفة واحدة يعني توقف كل الطلبات — حتى غير المرتبطة بها.
• تغيير بسيط في وظيفة يتطلب إعادة نشر التطبيق بأكمله.

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

5️⃣ Decoupling: Microservices Architecture — الفصل: بنية الخدمات المصغرة

📖 حل مشكلة التطبيقات المتجانسة هو تقسيمها إلى خدمات مصغرة (Microservices) — كل خدمة تؤدي وظيفة واحدة وتعمل في عملية مستقلة وتحافظ على بياناتها الخاصة.
بنية الخدمات المصغرة (Microservices architecture) تسمح لكل خدمة بالتوسع بشكل مستقل، والفشل بشكل مستقل، والنشر بشكل مستقل — مما يقلل بشكل كبير من تأثير أي مشكلة على بقية النظام.

📋 خصائص الخدمات المصغرة:

• كل خدمة تعمل في حاوية (Container) مستقلة — توسيع خدمة لا يؤثر على الخدمات الأخرى.
• فشل خدمة واحدة لا يؤثر على بقية الخدمات — النظام يستمر في العمل.
• تغيير أو تحديث خدمة واحدة لا يتطلب إعادة نشر التطبيق بأكمله.

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

الاقتران المتماسك مثل قطار واحد — إذا تعطلت قاطرة واحدة، توقف القطار كلّه والجميع ينتظر.
الخدمات المصغرة مثل سيارات أجرة منفصلة — إذا تعطلت سيارة، بقية السيارات تواصل طريقها والركاب الآخرون لا يتأثرون.
كل سيارة تختار طريقها وسرعتها المناسبة.

✅ خلاصة: فصل البنية المعمارية

• الاقتران المتماسك (Tight coupling) يعني أن المكونات تعتمد على بعضها — فشل واحد يؤدي لفشل الباقي.
• التواصل المتزامن بين الطبقات يخلق نقاط فشل فردية ويعيق التوسع.
• موازنات الأحمال مثل ELB تفصل الطبقات على مستوى البنية التحتية وتدير الأعطال تلقائياً.
• التطبيقات المتجانسة تعاني من مشاكل مماثلة داخل التطبيق نفسه.
• الخدمات المصغرة (Microservices) تحل المشكلة بتقسيم التطبيق إلى وحدات مستقلة.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Tight coupling	الاقتران المتماسك	مكونات تعتمد على بعضها البعض — فشل واحد يسبب فشل الباقي.
Loose coupling	الاقتران المرن / الفصل	مكونات مستقلة — كل مكون يعمل ويفشل ويتوسع لوحده.
Three-tier architecture	بنية ثلاثية الطبقات	بنية تفصل التطبيق إلى طبقة عرض ومنطق وبيانات.
Monolithic application	التطبيق المتجانس	تطبيق تجتمع فيه كل الوظائف في وحدة برمجية واحدة.
Microservices	الخدمات المصغرة	خدمات صغيرة مستقلة — كل واحدة تؤدي وظيفة محددة.
Synchronous	متزامن	نوع اتصال حيث يرسل المصدر طلباً وينتظر الرد قبل المتابعة.
Elastic Load Balancing	موازن الأحمال المرن	خدمة توزع حركة المرور عبر خوادم متعددة وتكتشف الأعطال.

1️⃣ Point-to-Point Messaging — التراسل المباشر من نقطة إلى نقطة

📖 التراسل من نقطة إلى نقطة (Point-to-point messaging) هو نموذج رسائل غير متزامن (Asynchronous) يتيح لتطبيقين التواصل عبر طابور (Queue) وسيط.
يُسمى Point-to-point لأن التطبيق المرسل يعرف التطبيق المستقبل ويرسل الرسائل إلى طابور محدد. التطبيق المرسل يُسمى المنتج (Producer) لأنه يولد الرسائل ويضعها في الطابور. التطبيق المستقبل يُسمى المستهلك (Consumer) لأنه يسحب الرسائل من الطابور ويعالجها عبر آلية السحب (Pull mechanism) — حيث يفحص الطابور دورياً للتحقق من وجود رسائل جديدة.

📋 خصائص التراسل من نقطة إلى نقطة:

• المنتج يضع رسالة في الطابور ← الطابور يخزّنها لحين طلبها.
• الرسالة قد تكون طلباً أو رداً أو خطأ أو معلومات — مثل سجلات العملاء أو أوامر الشراء أو الفواتير.
• المستهلك يسحب الرسالة عبر الاستقصاء الدوري (Polling) ويعالجها ثم يحذفها.
• الطابور يعمل كمستودع مؤقت يفصل المنتج عن المستهلك — كلاهما يعمل بالسرعة التي تناسبه.

تطبيق لمعالجة الطلبات: العميل يقدم طلباً ← خدمة استلام الطلبات (المنتج) تضع رسالة في طابور SQS.
تطبيق التوصيل (المستهلك) يسحب الرسالة ويعالج الطلب.
إذا كان تطبيق التوصيل مشغولاً، ينتظر الطلب في الطابور بأمان.
لا يضيع أي طلب ولا يتأثر العميل بسرعة المعالجة.

2️⃣ Amazon Simple Queue Service (Amazon SQS) — خدمة الطوابير البسيطة

📖 Amazon Simple Queue Service (Amazon SQS) هو خدمة طوابير رسائل مُدارة بالكامل تتيح فصل مكونات التطبيق بحيث تعمل وتفشل بشكل مستقل.
تعمل Amazon SQS كممتص صدمات بين المرسلين والمستقبلين — حيث تخزّن الرسائل مؤقتاً وتسمح لكل مكون بالعمل بالسرعة التي تناسبه. تستطيع الخدمة معالجة مليارات الرسائل يومياً وتخزين جميع الطوابير والرسائل ضمن منطقة AWS واحدة مع نسخ احتياطية عبر مناطق توفر متعددة.

📋 مميزات Amazon SQS الأساسية:

• مُدار بالكامل — لا حاجة لإدارة البنية التحتية للرسائل أو البرمجيات الوسيطة.
• موثوقية عالية — تخزين الرسائل على خوادم متعددة يضمن عدم فقدان أي رسالة.
• أمان — تشفير الرسائل باستخدام Server-Side Encryption (SSE) عبر AWS KMS، وفك التشفير فقط للمستهلك المصرح له.
• قابلية توسع هائلة — يتوسع تلقائياً بناءً على الاستخدام دون أي تهيئة مسبقة.

🔑 نصيحة أساسية: Amazon SQS ليس مجرد طابور رسائل عادي — بل هو ممتص الصدمات الذي يحمي تطبيقك من التقلبات المفاجئة في الضغط. عندما يزداد عدد الطلبات فجأة، يمتصها الطابور وتظل واجهة التطبيق سريعة وسلسة.

متجر إلكتروني يستخدم SQS لفصل استلام الطلبات عن معالجة الدفع.
الموقع يضع رسالة الطلب في الطابور ويرد للعميل فوراً بأن الطلب قيد المعالجة.
العميل راضٍ ولا ينتظر.
خلف الستار، خدمة الدفع تسحب الرسائل وتعالجها بالسرعة التي تناسبها.
حتى عندما يأتي آلاف الطلبات فجأة في موسم العروض، الطابور يمتص الضغط ولا يتأثر الموقع.

3️⃣ Amazon SQS Core Components — المكونات الأساسية لـ Amazon SQS

📖 تتكون Amazon SQS من ثلاثة مكونات أساسية: الرسالة (Message)، الطابور (Queue)، وطابور الرسائل الميتة (Dead-letter queue (DLQ)).
الرسالة هي وحدة البيانات المرسلة — حجمها يصل إلى 256 كيلوبايت (يمكن تمديده إلى 2 جيجابايت باستخدام المكتبة الموسعة). الطابور هو المستودع المؤقت الذي يحتفظ بالرسائل حتى معالجتها. طابور الرسائل الميتة (DLQ) هو طابور خاص يرتبط بالطابور الأساسي لاستقبال الرسائل التي فشلت معالجتها بعد تجاوز الحد الأقصى لعدد المحاولات.

📋 تفاصيل المكونات الأساسية:

• Message: حجم أقصى 256 كيلوبايت — تبقى في الطابور حتى تُحذف أو تنتهي مدة الاحتفاظ (افتراضي 4 أيام، أقصى 14 يوماً).
• Queue: نوعان — قياسي (Standard) وFIFO. يمكن تهيئة مدة الاحتفاظ، مهلة الرؤية (Visibility timeout)، وزمن انتظار استلام الرسالة.
• DLQ: يخزّن الرسائل الفاشلة — مثل طابور عادي يمكن القراءة منه والحذف — يجب أن يكون من نفس نوع الطابور الأصلي (Standard مع Standard، FIFO مع FIFO).

تطبيق معالجة صور: يضع مهمة تحويل صورة كرسالة في طابور SQS.
إذا كانت الصورة تالفة وفشلت المعالجة ثلاث مرات متتالية، تنتقل الرسالة تلقائياً إلى DLQ.
في نهاية اليوم، يراجع المطور طابور DLQ ويرى سبب الفشل.
بدلاً من فقدان المهمة إلى الأبد، أصبحت في انتظار المراجعة والتصحيح.

تخيل أن Amazon SQS مثل صندوق بريد إلكتروني.
المنتج يكتب رسالة ويضعها في صندوق البريد ويمضي في عمله.
المستهلك يفتح الصندوق في الوقت المناسب ويقرأ الرسالة ويعالجها.
إذا كانت الرسالة غير قابلة للقراءة (فاشلة)، تنتقل تلقائياً إلى مجلد البريد المهمل (DLQ) ليراجعها المسؤول لاحقاً.
بهذه الطريقة، لا تضيع أي رسالة ولا يتوقف أي طرف بسبب انشغال الطرف الآخر.

4️⃣ Decoupling Example: Amazon SQS — مثال على الفصل باستخدام Amazon SQS

📖 في السيناريو الكلاسيكي للفصل، لدينا تطبيق لاستلام الطلبات (Order capture) وتطبيق آخر لتنفيذها (Order fulfillment) — ندخل طابور SQS بينهما لنفصل كل منهما عن الآخر.
تطبيق استلام الطلبات (المنتج) يعمل على ثلاث مثيلات خلف موازن أحمال ALB — كل مثيل يضع الطلبات كرسائل في طابور "طلبات العملاء". تطبيق التنفيذ (المستهلك) يعمل على مثيلين يسحبان الرسائل ويعالجانها ثم يحذفانها بعد النجاح.

📋 فوائد هذا النموذج المفصول:

• الطابور يمتص التقلبات المفاجئة في الضغط — التطبيقان يتوسعان كل على حدة.
• يمكن معالجة الطلبات بالسرعة التي تناسب إدارة التكاليف — ليست هناك حاجة للمعالجة الفورية.
• إذا حدث خطأ في المعالجة، يمكن إعادة المحاولة أو توجيه الرسالة إلى Dead-letter queue لإعادة المعالجة لاحقاً.

تطبيق المقهى — ثلاث مثيلات لاستلام الطلبات خلف ALB.
كل مثيل يضع الطلب في طابور "Customer Orders" في SQS.
تطبيق التوصيل على مثيلين يسحبان الطلبات ويعالجانها بالسرعة المناسبة.
في شهر العروض، زادت الطلبات عشرة أضعاف.
الطابور امتص الزيادة — تطبيق استلام الطلبات لم يتأثر وتطبيق التوصيل اشتغل حتى أنجز المهام.

5️⃣ Queue Types: Standard vs FIFO — أنواع الطوابير: القياسي و FIFO

📖 يدعم Amazon SQS نوعين من الطوابير: الطابور القياسي (Standard queue) للسرعة والإنتاجية العالية، وطابور FIFO للترتيب الدقيق والتوصيل مرة واحدة.
الاختيار بينهما يعتمد على متطلبات تطبيقك: هل يمكن للرسالة أن تصل أكثر من مرة وبترتيب مختلف؟ استخدم Standard. هل يجب أن تصل بالترتيب ومرة واحدة بالضبط؟ استخدم FIFO.

الخاصية	Standard Queue	FIFO Queue
التوصيل	At-least-once — قد تُوصّل الرسالة أكثر من مرة	Exactly-once — تُوصّل مرة واحدة بالضبط
الترتيب	Best-effort — ترتيب تقريبي، قد تختلف الرسائل عن ترتيب الإرسال	First-In-First-Out — ترتيب دقيق تماماً كما أُرسلت
الإنتاجية	غير محدودة تقريباً — ملايين الطلبات في الثانية	حتى 300 طلب API/ثانية أو 3000 مع تجميع 10 رسائل
الاستخدام الأمثل	عندما لا يهم الترتيب ولا مشكلة من التكرار	عندما الترتيب والتوصيل مرة واحدة أمران حاسمان

Standard Queue يناسب إشعارات التطبيق — إذا وصلت رسالة مكررة أو خارج الترتيب، لا توجد مشكلة.
FIFO Queue يناسب المعاملات البنكية — الخصم يجب أن يسبق الإيداع وبالترتيب الصحيح، وكل معاملة مرة واحدة فقط.
اختيار النوع المناسب يمنع مشاكل مستقبلية ويحسن أداء التطبيق.

6️⃣ Queue Configuration: Polling Type — إعدادات الطابور: نوع الاستقصاء

📖 عند إنشاء طابور SQS، تحتاج إلى تحديد نوع الاستقصاء — Short polling أو Long polling — والفرق بينهما يؤثر على التكلفة والأداء.
معامل Receive message wait time يتحكم في نوع الاستقصاء. القيمة صفر تعني Short polling، أي قيمة أكبر من صفر (حتى 20 ثانية) تعني Long polling.

📋 مقارنة بين Short polling و Long polling:

• Short polling (الصفر): يستقصي مجموعة فرعية من الخوادم — يعيد الرد فوراً حتى لو كان فارغاً — استجابة سريعة لكن تكلفة أعلى بسبب الاستجابات الفارغة الكثيرة.
• Long polling (قيمة موجبة): يستقصي كل الخوادم — ينتظر حتى تنتهي مهلة الانتظار أو تصل رسالة — استجابات أقل ← تكلفة أقل.

🔑 نصيحة أساسية: في معظم الحالات، Long polling هو الخيار الأفضل لأنه يقلل التكلفة بشكل كبير. الاستثناءات تشمل التطبيقات التي تحتاج استجابة فورية لطلبات الاستقصاء (مثل أسعار الأسهم الحية) أو عندما يستخدم تطبيقك خيطاً واحداً لاستقصاء طوابير متعددة.

تطبيق يستقبل 100 رسالة في الساعة.
مع Short polling (كل ثانية): 3,600 استقصاء في الساعة — 3,500 منها فارغة بتكلفة عالية.
مع Long polling (كل 20 ثانية): 180 استقصاء في الساعة فقط — تكلفة أقل بحوالي 20 مرة.
والرسائل تصل فور وصولها إلى الطابور مع Long polling—لا فرق في وقت الاستجابة للرسالة الأولى.

7️⃣ Queue Configuration: Visibility Timeout — إعدادات الطابور: مهلة الرؤية

📖 Visibility timeout هي المدة الزمنية التي يمنع فيها Amazon SQS المستهلكين الآخرين من رؤية ومعالجة نفس الرسالة — لمنع المعالجة المزدوجة والتكرار.
أثناء مهلة الرؤية، يجب على المستهلك معالجة الرسالة ثم حذفها من الطابور. إذا فشل المستهلك في حذف الرسالة قبل انتهاء المهلة، تعود الرسالة مرئية لمستهلكين آخرين وقد تُعالج مرة أخرى.

📋 خصائص مهلة الرؤية:

• القيمة الافتراضية: 30 ثانية. الحد الأقصى: 12 ساعة.
• يجب ضبطها على أقصى وقت متوقع لمعالجة الرسالة وحذفها — لا أقل ولا أكثر.
• إذا انتهت المهلة قبل الحذف، تصبح الرسالة مرئية لمستهلك آخر وقد تُعالج مرتين.

تطبيق تحويل فيديو — معالجة الفيديو تستغرق بين دقيقتين وثلاث دقائق.
ضبطنا Visibility timeout على 4 دقائق — دقيقة زيادة عن أقصى وقت.
في فيديو طويل استغرق 5 دقائق، انتهت المهلة قبل الحذف.
سحب مستهلك آخر الرسالة وعالجها — وهكذا لم يضيع الفيديو.
المهلة المناسبة تمنع فقدان المهام مع تجنب المعالجة المزدوجة غير الضرورية.

8️⃣ How SQS Message Queueing Works — دورة حياة رسالة في Amazon SQS

📖 دورة حياة رسالة في SQS تتبع أربع خطوات: يرسلها المنتج ← يخزّنها الطابور ← يسحبها المستهلك ← يعالجها ويحذفها.
بعد أن يرسل المنتج الرسالة، يوزّعها SQS عبر خوادم متعددة للتكرار. عندما يسحب المستهلك الرسالة، تبدأ مهلة الرؤية وتختفي الرسالة عن المستهلكين الآخرين. بعد المعالجة الناجحة، يجب على المستهلك حذف الرسالة صراحة — SQS لا يحذفها تلقائياً.

📋 الخطوات بالتفصيل:

• 1. المنتج يرسل رسالة ← يوزعها SQS عبر خوادم الطابور بشكل متكرر.
• 2. المستهلك يطلب ويستلم الرسالة ← تبدأ مهلة الرؤية ← الرسالة تختفي عن المستهلكين الآخرين.
• 3. المستهلك يعالج الرسالة ويحذفها من الطابور خلال مهلة الرؤية — هكذا لا تُعالج مرة أخرى.
• إذا فشل: تنتهي المهلة ← تعود الرسالة مرئية لمستهلك آخر ← يضمن ذلك معالجتها في النهاية.

مستهلك سحب رسالة طلب من طابور SQS.
بدأت مهلة الرؤية 40 ثانية.
المستهلك يعمل: يتصل بقاعدة البيانات لتأكيد الدفع، يحدّث المخزون، يرسل إشعاراً.
بعد النجاح، يحذف الرسالة من الطابور.
إذا تعطل المستهلك قبل الحذف، بعد 40 ثانية يسحب مستهلك آخر الرسالة ويعالجها.
الطلب لا يضيع أبداً.

9️⃣ Amazon SQS Use Cases — حالات استخدام Amazon SQS

📖 أربع حالات استخدام رئيسية لـ Amazon SQS: طوابير العمل، التخزين المؤقت والتجميع، تفريغ الطلبات، وتحفيز التوسع التلقائي.
كل حالة استخدام تستفيد من قدرة الطابور على فصل المكونات غير المتزامنة وامتصاص التقلبات في الضغط.

📋 حالات الاستخدام بالتفصيل:

• Work queues: فصل مكونات تطبيق موزع تعالج العمل بمعدلات مختلفة — مثال: نظام ملاحة يجمع بيانات من آلاف السيارات يخزّنها في طابور ثم يعالجها.
• Buffering and batch operations: تخزين مؤقت ضد التقلبات — مثال: تطبيق تداول يفصل تسجيل الصفقات اللحظية عن تحديث أرصدة العملاء في المساء.
• Request offloading: نقل العمليات البطيئة خارج مسار الطلب التفاعلي — مثال: تطبيق بنكي يفصل واجهة الدفع الأمامية عن معالجة الفاتورة الخلفية.
• Trigger Auto Scaling: عدد الرسائل في الطابور يحدد حجم مجموعة Auto Scaling — مثال: إنذار CloudWatch يضيف مثيلات عندما يتجاوز عدد الرسائل 10.

تطبيق معالجة طلبات يعمل على مجموعة Auto Scaling.
يراقب CloudWatch عدد الرسائل في طابور SQS؛ إذا تجاوز 10 رسائل، يضيف Auto Scaling مثيل EC2 جديداً لاستيعاب الضغط.
عندما يقل العدد عن الحد، يزيل المثيلات الزائدة تلقائياً.
هذه إدارة ذكية للتكلفة والأداء — تدفع فقط مقابل ما تحتاجه فعلاً.

✅ خلاصة: فصل التطبيقات باستخدام Amazon SQS

• Amazon SQS هو خدمة طوابير رسائل مُدارة بالكامل تفصل مكونات التطبيق.
• نوعان من الطوابير: Standard (إنتاجية عالية، ترتيب تقريبي) و FIFO (ترتيب دقيق، توصيل مرة واحدة).
• الرسائل الفاشلة تنتقل إلى Dead-letter queue (DLQ) بدلاً من الضياع.
• Long polling يقلل التكلفة — استخدمه في معظم الحالات ما لم تكن تحتاج استجابة فورية.
• Visibility timeout يمنع المعالجة المزدوجة — اضبطه حسب أقصى وقت معالجة متوقع.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon SQS	خدمة الطوابير البسيطة	خدمة طوابير رسائل مُدارة تفصل مكونات التطبيق.
Producer	المنتج	التطبيق الذي يولد الرسائل ويضعها في الطابور.
Consumer	المستهلك	التطبيق الذي يسحب الرسائل من الطابور ويعالجها.
Standard Queue	الطابور القياسي	توصيل مرة على الأقل — ترتيب تقريبي — إنتاجية غير محدودة.
FIFO Queue	طابور FIFO	توصيل مرة واحدة بالضبط — ترتيب دقيق — إنتاجية محدودة.
Visibility timeout	مهلة الرؤية	مدة إخفاء الرسالة عن المستهلكين الآخرين أثناء المعالجة.
Dead-letter queue (DLQ)	طابور الرسائل الميتة	طابور للرسائل الفاشلة بعد تجاوز العدد الأقصى للمحاولات.
Long polling	الاستقصاء الطويل	يستقصي كل الخوادم وينتظر — يقلل التكلفة والاستجابات الفارغة.

1️⃣ Publish/Subscribe (Pub/Sub) Messaging — التراسل بنشر/اشتراك

📖 نشر/اشتراك (Publish/Subscribe (Pub/Sub) messaging) هو نموذج رسائل غير متزامن يفصل التطبيقات عبر موضوع (Topic) وسيط — ناشر واحد يرسل رسالة ومشتركون متعددون يستقبلونها فوراً.
في هذا النموذج، التطبيق المرسل يُسمى الناشر (Publisher) ولا يحتاج إلى معرفة أي شيء عن المستقبلين. التطبيقات المستقبلة تُسمى المشتركين (Subscribers) — يعبرون عن اهتمامهم باستلام الرسائل بالاشتراك في الموضوع. تُدفع الرسائل فوراً إلى جميع المشتركين عبر آلية الدفع (Push mechanism) دون حاجة للاستقصاء الدوري.

📋 خصائص Pub/Sub:

• الناشر ينشر رسالة إلى Topic واحد ← تُدفع تلقائياً لكل المشتركين فوراً.
• المواضيع لا تخزّن الرسائل — تدفعها فوراً (على عكس الطوابير التي تحتفظ بها لحين السحب).
• المشتركون يؤدون وظائف مختلفة بنفس الرسالة بالتوازي — دون علم الناشر بهم.
• الناشر لا يعرف المشترك ولا المشترك يعرف الناشر — فصل تام في المعرفة والمسؤولية.

في مقهى فرانك، عندما يصبح المشروب جاهزاً، يريد النظام إشعار الزبائن بعدة طرق مختلفة.
ينشر التطبيق رسالة واحدة إلى Topic "مشروب جاهز".
المشتركون: تطبيق الجوال يتلقى إشعاراً للزبون، البريد الإلكتروني يتلقى إيصالاً ضريبياً، ونظام المخزون يحدّث الكمية.
نفس الرسالة تنطلق إلى ثلاثة وجهات مختلفة بالتوازي — دون أن يعرف الناشر بمن يرسل.

2️⃣ Amazon Simple Notification Service (Amazon SNS) — خدمة الإشعارات البسيطة

📖 Amazon Simple Notification Service (Amazon SNS) هو خدمة Pub/Sub مُدارة بالكامل — تتيح إعداد وتشغيل وإرسال الإشعارات من السحابة عبر آلية الدفع (Push).
صُممت Amazon SNS لتلبية احتياجات أكبر التطبيقات وأكثرها تطلباً — تستطيع نشر عدد غير محدود من الرسائل في أي وقت. مع عدم وجود أعباء صيانة أو إدارة وتسعير الدفع حسب الاستخدام، تمنح SNS المطورين آلية قوية لدمج نظام إشعارات متكامل مع تطبيقاتهم.

📋 مميزات Amazon SNS:

• مُدار بالكامل — لا صيانة أو إدارة — تسعير الدفع حسب الاستخدام (Pay-as-you-go).
• يخزّن نسخاً متعددة من الرسالة على أقراص عبر مناطق توفر متعددة قبل تأكيد الاستلام للناشر.
• بعد النشر الناجح، يحذف SNS الرسالة — لا يحتفظ بها مثل SQS.
• يدعم TLS لتأمين قناة الاتصال — سياسات للتحكم في من يستطيع النشر والاشتراك.

خادم الإنتاج اكتشف أن استخدام CPU تجاوز 90% — نشر رسالة فوراً إلى SNS Topic "تنبيهات النظام".
المشتركون: بريد إلكتروني لمسؤول النظام، رسالة SMS لمسؤول الأمن، دالة Lambda تُطبق الإصلاح التلقائي.
كل هذا يحدث في ثوانٍ معدودة دون أي تدخل يدوي — استجابة سريعة تنقذ النظام قبل الانهيار.

3️⃣ Subscriber Types — أنواع المشتركين في Amazon SNS

📖 يدعم Amazon SNS سبعة أنواع من المشتركين — من البريد الإلكتروني التقليدي إلى خدمات AWS المتقدمة مثل Lambda وKinesis Data Firehose.
هذا التنوع يمنحك مرونة هائلة في توجيه الإشعارات — رسالة واحدة تصل إلى وجهات مختلفة تماماً كل منها يعالجها بطريقته.

📋 أنواع المشتركين السبعة:

• Email: إرسال الرسالة إلى بريد إلكتروني — كنص عادي أو JSON.
• SMS: رسالة نصية إلى رقم جوال — للتنبيهات العاجلة.
• Mobile push: إشعار دفع إلى تطبيق جوال — لتحديث التطبيق أو إعلام المستخدم.
• HTTP/HTTPS: إرسال HTTP POST إلى عنوان URL محدد.
• AWS Lambda: استدعاء دالة Lambda لتنفيذ منطق أعمال مخصص.
• SQS queue: إرسال الرسالة إلى طابور SQS لمعالجتها لاحقاً.
• Kinesis Data Firehose: إرسال الرسالة إلى تدفق Firehose للتخزين والتحليل.

شركة توصيل تستخدم Topic واحداً "طلب جديد".
مشترك عبر البريد الإلكتروني يتلقى إيصالاً إلكترونياً.
مشترك عبر SMS يتلقى رسالة "طلبك في الطريق".
مشترك عبر طابور SQS يحدّث المخزون.
مشترك عبر دالة Lambda يرسل إشعاراً للتطبيق.
كل مشترك يستقبل نفس الرسالة — لكن كل واحد يعالجها بطريقته المخصصة.

4️⃣ Amazon SNS Use Cases — حالات استخدام Amazon SNS

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

📋 حالات الاستخدام بالتفصيل:

• Application and system alerts: إشعار فوري عند وقوع حدث — مثل تغيير في مجموعة Auto Scaling.
• Push email and SMS: إرسال عناوين أخبار مستهدفة للمشتركين — مثل نشرة إخبارية يومية.
• Mobile push notifications: إشعارات تحديث لتطبيقات الجوال — "تحديث متوفر" مع رابط تحميل.

تطبيق أخبار عاجلة: المستخدمون يشتركون في Topic "أخبار عاجلة".
عند حدوث حدث مهم، ينشر الناشر الخبر العاجل.
يدفع Topic لكل المشتركين: الأول عبر البريد الإلكتروني للتفاصيل الكاملة، الثاني عبر SMS للخبر العاجل جداً، الثالث عبر إشعار تطبيق جوال للتنبيه الفوري.
الجميع يتلقى الخبر في نفس اللحظة — كل واحد بالطريقة التي تناسبه.

5️⃣ Decoupling Example: Using Amazon SQS with Amazon SNS — مثال: استخدام Amazon SNS مع Amazon SQS (Fanout)

📖 سيناريو التوزيع المتعدد (Fanout) يجمع بين قوة SNS وSQS: تُنشر رسالة واحدة إلى Topic ثم تُنسخ وتُدفع إلى طوابير SQS متعددة — كل طابور يعالجها بشكل مستقل.
هذا السيناريو مثالي للمعالجة المتوازية غير المتزامنة — مثلاً عند تحميل صورة تحتاج إلى تحويلها إلى ثلاث أحجام مختلفة.

📋 خطوات سيناريو Fanout:

• 1. تطبيق جوال يرفع صورة إلى Amazon S3.
• 2. إشعار حدث S3 ينشر رسالة تحتوي على رابط الصورة إلى SNS Topic.
• 3. الـ Topic يوزّع (fans out) الرسالة فوراً إلى ثلاث طوابير SQS: thumbnail، mobile، web.
• 4. كل طابور تراقبه مجموعة Auto Scaling خاصة — تعالج الحجم المخصص لها.
• 5. كل تطبيق يخزّن النتيجة في S3 — بشكل مستقل ومتوازٍ عن البقية.

تطبيق شبيه بإنستغرام: مستخدم يرفع صورة ← S3 يرسل إشعاراً إلى SNS Topic.
Topic يوزّع الصورة على ثلاثة طوابير: thumbnail تكبر صورة مصغرة، mobile تضبط للشاشات الصغيرة، web تحسن للعرض على سطح المكتب.
كل تطبيق يعمل بالتوازي في مجموعة Auto Scaling خاصة به.
تتحول الصور إلى الأحجام الثلاثة في دقائق بدلاً من أن ينتظر المستخدم وحده.

تخيل أن SQS صندوق بريد شخصي وSNS محطة راديو.
في صندوق البريد: شخص واحد يضع الرسالة، شخص واحد فقط يفتح الصندوق ويأخذها.
في الراديو: المحطة تبث إشارة وكل من لديه راديو يستقبلها فوراً — السائق في سيارته، الطباخ في مطبخه، الرياضي في ناديه.
نفس البث — ردود فعل مختلفة.

6️⃣ Amazon SNS Considerations — اعتبارات استخدام Amazon SNS

📖 هناك عدة اعتبارات مهمة عند استخدام Amazon SNS: كل رسالة تحتوي على رسالة واحدة فقط، ولا يوجد خيار لاسترجاع الرسالة بعد تسليمها بنجاح.
يدعم SNS نوعين من المواضيع — قياسي (Standard) للترتيب التقريبي وFIFO للترتيب الدقيق. كما يمكن تخصيص سياسة إعادة المحاولة لنقاط نهاية HTTP/HTTPS.

📋 الاعتبارات بالتفصيل:

• كل إشعار يحتوي على رسالة واحدة منشورة — لا يمكن استرجاعها بعد التسليم الناجح.
• نوعان من المواضيع: Standard (ترتيب تقريبي — قد تصل الرسائل بترتيب مختلف) وFIFO (ترتيب دقيق — تصل كما أُرسلت).
• يمكن تخصيص سياسة إعادة المحاولة لنقطة نهاية HTTP/HTTPS للتحكم في سلوك إعادة المحاولة حسب سعة الخادم.
• بعد استنفاد سياسة إعادة المحاولة، يتوقف SNS ويتجاهل الرسالة — إلا إذا أُرفق Dead-letter queue بالاشتراك.

تطبيق إشعارات يستخدم نقطة نهاية HTTP مخصصة.
توقف الخادم الخارجي فجأة.
يعيد SNS المحاولة وفقاً للسياسة المخصصة — ثلاث محاولات كل خمس دقائق.
بعد ذلك، تذهب الرسالة إلى DLQ بدلاً من الضياع.
الفريق يراجع DLQ في الصباح ويعالج الإشعارات الفاشلة.

✅ خلاصة: فصل التطبيقات باستخدام Amazon SNS

• Amazon SNS هو خدمة Pub/Sub مُدارة — Topic واحد ينشر والمشتركون يستقبلون فوراً.
• يدعم 7 أنواع من المشتركين: Email، SMS، Push، HTTP، Lambda، SQS، Kinesis Firehose.
• سيناريو Fanout يوزع رسالة Topic على طوابير SQS متعددة — معالجة متوازية غير متزامنة.
• استخدم DLQ مع SNS لضمان عدم فقدان الرسائل الفاشلة بعد استنفاد محاولات التسليم.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon SNS	خدمة الإشعارات البسيطة	خدمة Pub/Sub مُدارة — واحد ينشر والكل يستقبل فوراً.
Topic	الموضوع	قناة اتصال — الناشر يرسل والمشتركون يستقبلون منه.
Publisher	الناشر	التطبيق الذي يرسل الرسائل إلى Topic.
Subscriber	المشترك	التطبيق الذي يستقبل الرسائل من Topic.
Push mechanism	آلية الدفع	SNS يدفع الرسالة فوراً للمشترك — دون استقصاء.
Fanout	التوزيع المتعدد	إرسال رسالة Topic إلى طوابير متعددة — معالجة متوازية.

1️⃣ Amazon MQ — خدمة وسيط الرسائل المُدارة للبيئات الهجينة

📖 Amazon MQ هو خدمة وسيط رسائل (Message broker) مُدارة بالكامل تدعم Apache ActiveMQ وRabbitMQ — يسهّل إعداد وتشغيل وسيط الرسائل في السحابة دون الحاجة لإدارة البنية التحتية.
وسيط الرسائل يسمح لأنظمة برمجية مختلفة — غالباً بلغات برمجة ومنصات مختلفة — بالتواصل وتبادل المعلومات. كخدمة مُدارة بالكامل، يقلل Amazon MQ أعباء التشغيل عبر إدارة التجهيز والإعداد والصيانة نيابة عنك.

📋 مميزات Amazon MQ:

• يدير التجهيز والإعداد والصيانة — أنت فقط تركز على تطبيقك.
• يدعم بروتوكولات مراسلة قياسية مفتوحة: JMS، NMS، AMQP، STOMP، MQTT، وWebSocket.
• يمكن الترحيل من أي وسيط رسائل يستخدم هذه المعايير — غالباً دون إعادة كتابة كود المراسلة.
• يدعم كلاً من الطوابير (Queues) والمواضيع (Topics) — حل متكامل للفصل.

شركة لديها تطبيق جافا يستخدم ActiveMQ داخل الشركة—تريد نقله إلى AWS.
بدلاً من إعادة كتابة كود JMS بالكامل، ترحل إلى Amazon MQ.
كل ما تغير هو عنوان نقطة النهاية — باقي الكود يعمل كما هو دون أي تعديل.
الشركة توفر تكاليف الصيانة والتراخيص وتحصل على وسيط رسائل أكثر استقراراً.

2️⃣ Amazon MQ Use Case: Hybrid Cloud Environment — حالة استخدام: البيئة السحابية الهجينة

📖 في البيئات الهجينة (Hybrid cloud)، Amazon MQ يربط التطبيقات الداخلية (On-premises) مع التطبيقات السحابية — تاركاً الأنظمة القديمة في مكانها دون تغيير.
هذا مهم بشكل خاص للمؤسسات الكبيرة التي لديها أنظمة رئيسية (Mainframe) مكلفة جداً لنقلها — لكنها لا تزال بحاجة للتواصل مع التطبيقات السحابية الحديثة. يمكن Amazon MQ أيضاً استدعاء دالة Lambda من طوابير ومواضيع Amazon MQ لدمج الأنظمة القديمة مع البنى اللاخدمية الحديثة.

📋 خطوات الربط في البيئة الهجينة:

• ينشئ المسؤول وسيط Amazon MQ لـ ActiveMQ في منطقة توفر واحدة.
• يكوّن الوسيط لتخزين الرسائل على قرص EBS محسّن لزمن انتقال منخفض وإنتاجية عالية.
• يرسل التطبيق الداخلي الرسائل إلى ActiveMQ ← يوجّهها الوسيط إلى التطبيق السحابي.
• يبقى التطبيق الداخلي دون تغيير — فقط تغيير وجهة الرسالة.

نظام محاسبة قديم داخل الشركة يريد إرسال فواتير إلى تطبيق سحابي جديد على AWS لمعالجتها.
ينشئ فريق التشغيل وسيط Amazon MQ لـ ActiveMQ — يخزّن الرسائل على قرص EBS محسّن.
النظام المحاسبي القديم يرسل الفاتورة — بدون تغيير ولا سطر كود واحد.
التطبيق السحابي يسحب الفاتورة ويعالجها.
النظام القديم أصبح يتحدث مع السحابة!

تخيل أن Amazon MQ مثل محطة قطار دولية.
قطارات قديمة (أنظمة داخلية) وقطارات حديثة (تطبيقات سحابية) كلها تلتقي في المحطة.
القطار القديم لا يحتاج تغيير قضبانه أو محركه—يصل إلى المحطة ويسلم الركاب.
القطار الحديث يستلمهم ويكمل الرحلة.
المحطة هي الجسر بين عالمين مختلفين دون تغيير أي منهما.

3️⃣ Choosing the Right Decoupling Solution — اختيار حل الفصل المناسب

📖 اختيار الأداة المناسبة يعتمد على حالتك: Amazon SQS وAmazon SNS للتطبيقات السحابية الجديدة، Amazon MQ للتطبيقات الهجينة وترحيل وسائط الرسائل الموجودة.
إذا كنت تبني تطبيقات جديدة في السحابة، توصي AWS باستخدام SQS وSNS — فهما خدمتان تستخدمان API ولا تتطلبان إعداد وسيط رسائل. أما إذا كنت تحتاج دمج التطبيقات الداخلية مع السحابية أو ترحيل وسيط رسائل موجود، فـ Amazon MQ هو الحل الأمثل.

المعيار	Amazon SQS	Amazon SNS	Amazon MQ
الاستخدام الأمثل	تطبيقات سحابية جديدة	تطبيقات سحابية جديدة	بيئات هجينة + ترحيل
نموذج الرسائل	Producer-Consumer	Publisher-Subscriber	كلاهما — طوابير ومواضيع
واجهة البرمجة	Amazon SQS API	Amazon SNS API	بروتوكولات قياسية (JMS, AMQP...)
التسعير	عدد الطلبات الشهري	عدد الطلبات + التوصيلات	بالساعة + بالجيجابايت

🔑 توصية AWS: للتطبيقات السحابية الجديدة → SQS وSNS. للبيئات الهجينة وترحيل وسائط الرسائل الموجودة → Amazon MQ — لأنه يدعم البروتوكولات القياسية ولا يتطلب إعادة كتابة الكود.

لدى شركة ثلاثة سيناريوهات مختلفة:
الأول: تطبيق جديد لفصل طلبات الدفع — تستخدم SQS لطابور المعاملات.
الثاني: إشعارات متعددة عند رفع ملف جديد — تستخدم SNS مع SQS بنمط Fanout.
الثالث: نظام مخزون قديم داخل الشركة يريد التحدث مع التطبيق السحابي الجديد — تستخدم Amazon MQ ببروتوكول JMS قياسي دون تغيير في الكود القديم.
كل أداة في مكانها الصحيح — تطبيق مرن ومستقبلي بالكامل.

💡 مقارنة سريعة:

العنصر	الخيار الأول	الخيار الثاني
Amazon SQS	طابور رسائل — نموذج Producer-Consumer — سحب (Pull) — استمرار الرسالة — تسعير بعدد الطلبات.	-
Amazon SNS	إشعارات Pub/Sub — نموذج Publisher-Subscriber — دفع (Push) — لا استمرار للرسالة — تسعير بعدد الطلبات والتوصيلات.	-
Amazon MQ	وسيط رسائل مُدار — طوابير ومواضيع — بروتوكولات قياسية — تسعير بالساعة والجيجابايت — مثالي للبيئات الهجينة والترحيل.	-

✅ خلاصة: فصل التطبيقات الهجينة باستخدام Amazon MQ

• Amazon MQ هو وسيط رسائل مُدارة لـ ActiveMQ وRabbitMQ في السحابة.
• يدعم بروتوكولات قياسية مفتوحة — JMS، AMQP، MQTT وغيرها.
• الحل الأمثل لربط البيئات الداخلية بالسحابية دون تغيير الكود القديم.
• SQS/SNS = تطبيقات سحابية جديدة. Amazon MQ = بيئات هجينة وترحيل.

📖 جدول المصطلحات

المصطلح (English)	الترجمة	المفهوم
Amazon MQ	أمازون إم كيو	وسيط رسائل مُدار لـ ActiveMQ و RabbitMQ.
Message broker	وسيط الرسائل	برمجية وسيطة تتيح لأنظمة مختلفة التواصل عبر رسائل.
ActiveMQ	أكتيف إم كيو	وسيط رسائل مفتوح المصدر — شائع في تطبيقات المؤسسات.
RabbitMQ	رابيت إم كيو	وسيط رسائل مفتوح المصدر — خفيف ومرن.
Hybrid cloud	البيئة السحابية الهجينة	بيئة تدمج البنية التحتية الداخلية مع خدمات السحابة.
JMS	خدمة رسائل جافا	واجهة برمجة رسائل قياسية لتطبيقات جافا.
AMQP	بروتوكول الرسائل المتقدم	بروتوكول مراسلة مفتوح ومعياري.

1. A company runs a monolithic application where order processing, payment, and inventory update happen in a single synchronous flow. During peak hours, the application becomes slow and orders fail. The company wants to decouple these components. Which approach is MOST appropriate?

A) Move all components to a larger EC2 instance B) Use Amazon SQS to introduce a queue between the order service and downstream services for asynchronous processing C) Use Amazon CloudFront to cache order requests D) Use Amazon Route 53 for latency-based routing

Correct! SQS decouples the components by allowing the order service to send messages to a queue. Downstream services (payment, inventory) process messages independently. If downstream services slow down, orders are still accepted and queued for later processing.

Incorrect. The correct answer is B. SQS provides asynchronous decoupling -- orders are stored in a queue and processed when capacity is available. Vertical scaling (bigger instance) is a temporary fix with limits. CloudFront caches content, not transactions. Route 53 is DNS, not a decoupling mechanism.

2. A media processing application uploads images to S3 and needs to generate thumbnails asynchronously. The application should process each image exactly once in the order they were uploaded. Which queue type should the architect use?

A) Amazon SQS Standard queue B) Amazon SQS FIFO queue C) Amazon MQ queue D) Amazon Kinesis Data Streams

Correct! SQS FIFO queues guarantee first-in-first-out delivery and exactly-once processing. Messages are delivered in the exact order they were sent, and duplicates are eliminated. This is essential for image processing where order matters.

Incorrect. The correct answer is B. FIFO queues guarantee order and exactly-once processing. Standard queues offer best-effort ordering and at-least-once delivery (possible duplicates). Amazon MQ is for migrating existing message brokers. Kinesis is for real-time streaming analytics, not simple queue processing.

3. A company needs to send the same event notification to multiple services: an SQS queue for processing, a Lambda function for real-time alerting, and an email subscription. Which AWS service should they use to broadcast the message?

A) Amazon SQS with multiple consumers B) Amazon SNS with a fan-out pattern C) AWS Step Functions D) Amazon EventBridge

Correct! Amazon SNS supports a fan-out pattern where one message is published to a topic and delivered to multiple subscribers (SQS queues, Lambda, email, HTTP endpoints) simultaneously. This is the standard pub/sub pattern for broadcasting events.

Incorrect. The correct answer is B. SNS fan-out sends a single message to multiple subscriber types. With SQS, each consumer would receive a different message -- you would need to send the same message to each queue separately. Step Functions coordinates workflows. EventBridge uses rules to route events but SNS is purpose-built for fan-out.

4. An application running on EC2 sends messages to an SQS queue. A downstream service polls the queue and processes messages. The processing time for each message varies. The company wants to ensure that if the downstream service fails while processing a message, the message is not lost and is retried. What SQS feature ensures this?

A) Visibility timeout -- the message becomes visible again after the timeout if not deleted B) Dead-letter queue -- sends failed messages to another queue for analysis C) Message retention period -- keeps the message for up to 14 days D) Long polling -- reduces empty responses

Correct! The visibility timeout hides a message from other consumers when it is received. If the consumer fails to delete the message within the timeout, it becomes visible again and can be reprocessed. This prevents message loss on consumer failure.

Incorrect. The correct answer is A. The visibility timeout is the built-in mechanism for retries on failure. A dead-letter queue captures messages after repeated failures but does not by itself handle retries. Message retention period keeps messages from being deleted but does not handle reprocessing. Long polling optimizes polling frequency, not error handling.

5. A company uses SQS and wants to minimize the cost of polling the queue when no messages are available. Currently, they poll every second even when the queue is empty, wasting API calls. Which solution reduces empty polling?

A) Set up a CloudWatch alarm when the queue is empty B) Increase the number of consumers C) Enable long polling with a maximum of 20 seconds D) Use SNS instead of SQS

Correct! Long polling allows consumers to wait for messages for up to 20 seconds instead of polling immediately. If no messages arrive during that period, an empty response is returned. This dramatically reduces the number of empty polls and saves API costs.

Incorrect. The correct answer is C. Long polling reduces empty returns by keeping the connection open. A CloudWatch alarm does not change polling behavior. More consumers would increase costs, not reduce them. SNS is push-based and does not solve the polling problem -- it is a different pattern.

6. A company processes financial transactions and must ensure that each message is processed exactly once and in the correct order. Messages should be consumed from SQS by multiple EC2 instances for horizontal scaling, but each group of related messages (e.g., all transactions for one account) must be processed in order. What should they use?

A) SQS Standard queue with multiple consumers B) SQS FIFO queue with message group IDs C) SQS FIFO queue with a single consumer D) Amazon Kinesis Data Streams

Correct! FIFO queues with message group IDs allow ordered processing within each group while still supporting multiple consumers. Messages with the same group ID are delivered to one consumer in order, while different groups can be processed by different consumers in parallel.

Incorrect. The correct answer is B. Message group IDs provide ordered processing within groups while allowing parallel consumption across groups. Standard queues do not guarantee order. A single consumer with FIFO would work but limits scalability. Kinesis is for real-time streaming, not exactly-once queue processing with simple consumer patterns.

7. A company has an existing on-premises application that uses JMS-compatible message queues. They are migrating to AWS and want to use a managed messaging service with minimal code changes. Which service should they choose?

A) Amazon SQS B) Amazon SNS C) Amazon MQ D) Amazon EventBridge

Correct! Amazon MQ is a managed message broker service that supports industry-standard protocols including JMS, AMQP, MQTT, and STOMP. It is compatible with existing applications that use ActiveMQ or RabbitMQ, minimizing code changes during migration.

Incorrect. The correct answer is C. Amazon MQ specifically supports JMS and other standard protocols. SQS and SNS use custom AWS APIs that would require significant code changes. EventBridge is for event-driven architectures, not traditional message queuing.

8. A company uses SNS to send notifications. They want subscribers to receive messages in a specific order and with exactly-once delivery semantics. How can they achieve these requirements?

A) SNS supports FIFO topics that provide ordering and exactly-once delivery B) Use SNS Standard topic and implement ordering in the subscriber C) Subscribe an SQS FIFO queue to the SNS topic to preserve ordering and deduplication D) Both A and C -- SNS FIFO topics support these features natively and work with SQS FIFO subscribers

Correct! SNS FIFO topics provide ordering and exactly-once delivery when used with SQS FIFO subscriber queues. Messages published to a FIFO topic are delivered in order to subscribed FIFO queues, preserving message ordering and deduplication across the entire path.

Incorrect. The correct answer is D. SNS FIFO topics (introduced in 2021) support both ordering and exactly-once delivery when used with SQS FIFO subscriber queues. Standard topics do not guarantee order. Implementing ordering at the subscriber level is complex and error-prone.

9. A company uses SQS and finds that some messages consistently fail processing, causing them to be retried repeatedly by consumers. This wastes processing capacity. How should the company handle these problematic messages?

A) Delete the failing messages manually from the queue B) Configure a dead-letter queue (DLQ) for the source queue after a maximum number of receives C) Increase the visibility timeout for all messages D) Use SNS instead of SQS

Correct! A dead-letter queue (DLQ) receives messages after a configurable maximum number of receive attempts. This isolates problematic messages so they do not block processing of healthy messages. The DLQ can be analyzed later to diagnose and fix the issue.

Incorrect. The correct answer is B. DLQs automatically isolate messages that repeatedly fail processing. Manual deletion is not scalable and may delete important data. Increasing visibility timeout does not prevent retries -- it just delays them. SNS does not solve the retry problem for queue processing.

10. A company wants to process orders from an e-commerce website. When an order is placed, the application must send an email confirmation, update inventory, and notify the shipping department. The company wants these tasks to happen independently so a failure in one does not affect the others. Which architecture should they use?

A) Process all tasks sequentially in a single Lambda function B) Publish the order event to an SNS topic with separate SQS queue subscriptions for each task C) Write all tasks to a single SQS queue for a single worker to process D) Use EC2 instances to process all tasks together

Correct! SNS fan-out to separate SQS queues for each task (email, inventory, shipping) creates a fully decoupled architecture. Each task has its own queue and can be processed independently. A failure in email sending does not block inventory updates or shipping notifications.

Incorrect. The correct answer is B. SNS fan-out to individual SQS queues provides independent processing for each task. Sequential processing means one failure blocks everything. A single queue with one worker creates a bottleneck. EC2 instances without decoupling reintroduces tight coupling.

🚀 الخاتمة

في هذه الوحدة، قطعنا رحلة كاملة من فهم مشكلة الاقتران المتماسك (Tight coupling) إلى تطبيق حلول الفصل المناسبة. بدأنا بتشخيص المشكلة — كيف أن المكونات المرتبطة تخلق نقاط فشل فردية وتعقيدات في التوسع — ثم انتقلنا إلى الحلول المتزامنة مثل موازنات الأحمال والخدمات المصغرة. تعمقنا في Amazon SQS كأداة طوابير تفصل التطبيقات عبر التراسل غير المتزامن مع نوعي الطوابير Standard وFIFO، وتعلمنا مفاهيم أساسية مثل مهلة الرؤية والاستقصاء الطويل وطابور الرسائل الميتة. استعرضنا Amazon SNS كخدمة Pub/Sub تدفع الرسائل فوراً لمشتركين متعددين مع سيناريو التوزيع المتعدد (Fanout) الذي يجمع قوة الخدمتين معاً. وأخيراً، تعرفنا على Amazon MQ — الحل الأمثل للبيئات الهجينة — لربط الأنظمة القديمة داخل الشركة مع التطبيقات السحابية الحديثة عبر بروتوكولات قياسية دون تغيير في الكود. تذكر دائماً: الفصل ليس رفاهية — بل هو الفرق بين تطبيق ينهار بكامله بسبب مشكلة صغيرة وتطبيق يستوعبها ويتجاوزها كأنها لم تحدث.

تعديل المقال