{"ar": "<p>الرواية الافتراضيّة للمعماريّة في المنطقة اليوم هي الخدمات المصغّرة. كلّ عرضٍ لمؤسّسٍ-CTO يحوي مخطّطاً بخمس عشرة صندوقاً وKafka في الوسط. أغلب الفرق خلف تلك العروض تضمّ اثني عشر مهندساً، وعشرة آلاف مستخدمٍ يوميّاً، وخارطة طريقٍ تُغيّر شكلها كلّ ستّة أسابيع.</p>\n<p>ليست هذه مشكلة خدماتٍ مصغّرة. بل مشكلة منظومةٍ أحاديّة، مُتنكّرة.</p><h2>ما هي المنظومة الأحاديّة المعياريّة فعلاً</h2><p>قاعدة كودٍ واحدة. أثر نشرٍ واحد. حوافّ خدمةٍ نظيفة داخل الكود — سياقاتٌ محدَّدة، ولا وصلاتُ جداولٍ عبر السياقات، ولا تكامل إلّا من خلال واجهاتٍ منشورة. حين تنظف الحوافّ، تستطيع رفع وحدةٍ خارج المنظومة إلى خدمتها الخاصّة يوم تحتاج ذلك فعلاً. لا قبله.</p><h2>أين يظهر الربح</h2><p>التصحيح عمليّة grep واحدة. النشر أثرٌ واحد، ومسار ترحيلٍ واحد، ومسار تراجعٍ واحد. إعادة الهيكلة عبر الحدّ بين وحدتَين هي PR اعتياديّ، لا جهد تنسيقٍ بين فريقَين لأسبوعَين. تُبقي خيار التقسيم لاحقاً دون أن تدفع كلفته الآن.</p>\n<p>في شركات النموّ السعوديّة والخليجيّة التي عملت معها، تفوّقت المنظومة الأحاديّة المعياريّة على مكافئها من الخدمات المصغّرة في <em>كلّ مقياسٍ يهمّ عملاً في تلك المرحلة</em>: زمن الوصول إلى ميزةٍ يراها التاجر، وزمن الإصلاح العاجل، وكلفة كلّ مهندس، وقدرة فريقٍ صغيرٍ على تحمّل مسؤوليّة المنتج كاملاً.</p><h2>متى تلجأ إلى الخدمات المصغّرة</h2><p>حين يكون لوحدةٍ من المنظومة ملفّ مقياسٍ مختلفٌ جوهريّاً — خدمةُ تتبّعٍ حيّةٍ مثلاً تحتاج تشغيلاً حاراً على أسطولٍ من العقد منخفضة الزمن، بينما يستقرّ بقيّة المنتج على خادمٍ اعتياديّ. أو حين تحتاج فرقٌ مستقلّة النشر بإيقاعاتٍ مستقلّة، وتفوق كلفةُ التنسيق ضريبةَ الحدّ. كلاهما محفّزٌ حقيقيّ. ولا واحد منهما هو "وظّفنا مهندس Kafka".</p>", "en": "<p>The default architecture pitch in the region right now is microservices. Every founder-CTO deck has a service diagram with fifteen boxes and Kafka in the middle. Most of the teams behind those decks have twelve engineers, ten thousand daily active users, and a product roadmap that changes shape every six weeks.</p>\n<p>That is not a microservices problem. That is a monolith problem, dressed up.</p><h2>What a modular monolith actually is</h2><p>One codebase. One deploy artefact. Clean service seams inside the code — bounded contexts, no cross-context table joins, integration only through published interfaces. When the seams are clean, you can lift a module out into its own service the day you actually need to. Not before.</p><h2>Where the win shows up</h2><p>Debugging is one grep. Deploys are one artefact, one migration path, one rollback. Refactoring across the seam of two modules is a normal PR, not a two-week cross-team coordination effort. You keep the option of splitting later without paying the cost of splitting now.</p>\n<p>On the Saudi and GCC scale-ups I have worked with, the modular monolith outperformed a microservice equivalent on <em>every metric that matters to a business at that stage</em>: time to a merchant-visible feature, time to a hotfix, cost per engineer, and the ability to keep a small team fully accountable for the product.</p><h2>When to reach for microservices</h2><p>When one module of the monolith has a fundamentally different scaling profile — say, a real-time tracking service that needs to run hot on a fleet of low-latency nodes while the rest of the product happily fits on a normal box. Or when independent teams need to deploy on independent cadences, and coordination cost genuinely outweighs the boundary tax. Both are real triggers. Neither of them is "we hired a Kafka engineer".</p>"}