ال Distributed Monolithic واحد من أسوا ال anti pattern في تصميم الأنظمة. طبعاً يجمع مشاكل الأنظمة الموزعة distributed system مع قيود الـ monolithic architecture.
غالباً الفكرة تبدأ لما تحاول “توزيع” نظامك، لكن بدلاً من تحقيق استقلالية الخدمات independently service، تنتهي بخدمات مترابطة بشكل وثيق coupled services. وبهذه الحالة أي فشل في service واحدة يؤدي إلى انهيار النظام بالكامل، وتفقد الفوائد الأساسية للـ microservices.
أحد الأسباب الرئيسية لهذه المشكلة هو الاعتماد على synchronous communication بين الخدمات، مثل REST APIs، أو مشاركة قاعدة بيانات واحدة. هذا النوع من الترابط يجعل كل خدمة تعتمد على الثانية، وإذا قررت تعديل قاعدة البيانات أو أي خدمة، يتطلب ذلك تحديث النظام بالكامل. النتيجة؟ تعقيد أكبر بدل أن يكون النظام مرناً ومستقلاً.
المشكلة الحقيقية غالباً تبدأ من سوء التخطيط. كثير يتحمس لفكرة microservices بدون فهم حقيقي لاحتياجات المشروع. التواصل بين ال services يحتاج أن يكون غير متزامن asynchronous . في message broker يضبطوا الموضوع ذا زي Kafka أو RabbitMQ، وكل service تحتاج قاعدة بياناتها الخاصة. لكن لو بُني النظام بطريقة مترابطة، فأنت لم توزع النظام إنما خلقت نسخة موزعة من الـ monolith.
Distributed Monolith يعطيك وهم التوزيع، لكنه يزيد التعقيد والمشاكل. لو مشروعك صغير أو متوسط، monolith مصمم بشكل جيد غالباً يكون أفضل. التوزيع ليس هدفاً بحد ذاته، بل أداة تُستخدم فقط إذا كانت حاجة المشروع تتطلبها.
Original source
This content was originally published as a LinkedIn post. Open it in a new tab.