ما هو Message Broker؟ ولماذا نحتاجه؟

لطالما كانت لدي أسئلة كثيرة حول ما فائدة Message Broker، وكلما حاولت أن أفهمه من الناحية التقنية البحتة، لم تتضح لي الرؤية بشكل كامل.
فالأسماء مثل RabbitMQ أو Kafka بدت معقدة، وبدون سياق معماري كان من الصعب استيعاب لماذا نحتاج أصلًا إلى هذا المكوّن.

لكن مؤخرًا، عندما بدأت أدرس المعماريات (Architectures) المختلفة مثل:

• Microservices Architecture
• Event-Driven Architecture

تغيرت الصورة تمامًا، وظهر لي الـ Message Broker كجزء طبيعي في هذه المنظومة.

معنى كلمة “Broker” = وسيط

قبل أن ندخل في التقنية، لنتوقف عند الكلمة نفسها:

• Broker معناها بالعربية وسيط.
• والوسيط هو: الشخص أو الشيء الذي يقع بين طرفين ويقوم بتسهيل التواصل أو التبادل بينهما.

هذه الفكرة البسيطة تمنحنا الانطباع الأول: إذا كان لدينا وسيط، فهو دائمًا يقف بين طرفين. إذن في حالتنا:
الوسيط بين من ومن؟

Microservices + Event-Driven

في الخدمات المصغّرة (Microservices) الفكرة الأساسية هي جعل كل خدمة مستقلة عن الأخرى.
وفي المعمارية القائمة على الأحداث (Event-Driven Architecture) الفكرة أن التواصل يتم عبر أحداث تُنشَر وتُستهلَك.

وهنا يبرز السؤال:
من الذي ينقل هذه الأحداث من منتِجها إلى مستهلكها؟
من الذي يضمن أن الخدمة التي أرسلت الحدث لا تحتاج أن تعرف تفاصيل الخدمة التي ستستقبله؟

الإجابة: الوسيط (Message Broker).

دور Message Broker

الـ Message Broker هو ذلك “الوسيط الذكي” في منتصف النظام، يقوم بـ:

1. استقبال الأحداث من المنتجين (Producers).
2. تخزينها مؤقتًا (في Queue أو Topic).
3. إيصالها إلى المستهلكين (Consumers) المناسبين.

وبهذا:

• نفصل الخدمات عن بعضها (Decoupling).
• نسمح لكل خدمة أن تعمل باستقلالية.
• نسهّل بناء أنظمة مرنة وقابلة للتوسع.

الخلاصة

من دون سياق معماري، قد يبدو Message Broker مجرد أداة تقنية غامضة.
لكن عندما نضعه داخل لوحة Microservices + Event-Driven Architecture يصبح مفهومه طبيعيًا جدًا:
هو ببساطة الوسيط الذي يربط الخدمات المستقلة عبر الأحداث.