feat(backend): initialize specialized documentation for rabbitmq

backend/expressjs/readme.md

@@ -174,7 +174,7 @@ Use `helmet` for automatic protection against XSS, clickjacking, and to hide fra
 app.use((req, res, next) => { res.header("Access-Control-Allow-Origin", "*"); next(); });
 ```
 ### ⚠️ Problem
-Using a wildcard (`*`) for CORS allows any domain to make authenticated requests to the API. This exposes the application to Cross-Site Request Forgery (CSRF) and unauthorized data access.
+Using a wildcard (`*`) for CORS allows ALL domains to make authenticated requests to the API. This exposes the application to Cross-Site Request Forgery (CSRF) and unauthorized data access.
 ### ✅ Best Practice
 ```javascript
 const cors = require('cors');

backend/microservices/security-best-practices.md

@@ -16,7 +16,7 @@ last_updated: 2026-03-27
 ## 1. 🛑 Implicit Trust Between Services
 ### ❌ Bad Practice
 ```javascript
-// Service A trusts Service B without any validation
+// Service A trusts Service B without strictly validating
 app.post('/internal/process', (req, res) => {
     // Process without checking authorization
 });

backend/mongodb/security-best-practices.md

@@ -77,7 +77,7 @@ Directly passing unsanitized user input (e.g., from a web request) into a MongoD
 
 ```javascript
 // Express.js example: Vulnerable to NoSQL Injection
-// If req.body.username = { "$gt": "" }, it matches any username
+// If req.body.username = { "$gt": "" }, it matches ALL usernames
 const user = await db.collection('users').findOne({
     username: req.body.username,
     password: req.body.password

backend/nodejs/architecture.md

@@ -120,4 +120,4 @@ const config = Object.freeze({
 });
 ```
 ### 🚀 Solution
-Configuration objects MUST be locked and immutable after initialization. FORBID any runtime mutations to the global execution environment.
+Configuration objects MUST be locked and immutable after initialization. FORBID ALL runtime mutations to the global execution environment.

backend/rabbitmq/readme.md

@@ -0,0 +1,89 @@
+---
+technology: RabbitMQ
+domain: backend
+level: Senior/Architect
+version: "3.x"
+tags: [best-practices, deterministic-code, architecture-patterns, vibe-coding, message-broker, distributed-systems, scalable-code]
+ai_role: Senior Backend Architect
+last_updated: 2026-03-27
+---
+
+# 🐇 RabbitMQ Best Practices & Production-Ready Patterns
+
+[⬅️ Back to Parent](../readme.md)
+
+## 🎯 Context & Scope
+- **Primary Goal:** Outline deterministic patterns for integrating RabbitMQ message brokering in backend applications.
+
+## 🗺️ Map of Patterns
+```mermaid
+graph TD
+    A[Publisher] --> B[Exchange]
+    B --> C[Queue 1]
+    B --> D[Queue 2]
+    C --> E[Consumer 1]
+    D --> F[Consumer 2]
+
+    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+    class A component;
+    class B layout;
+    class C component;
+    class D component;
+    class E component;
+    class F component;
+```
+
+## 1. 🛑 Missing Dead Letter Exchanges (DLX)
+### ❌ Bad Practice
+```javascript
+channel.assertQueue('task_queue', { durable: true });
+```
+### ⚠️ Problem
+Failing to configure a Dead Letter Exchange means messages that repeatedly fail processing WILL loop infinitely or be dropped silently. This causes severe resource exhaustion and silent data loss.
+### ✅ Best Practice
+```javascript
+channel.assertExchange('dlx_exchange', 'direct', { durable: true });
+channel.assertQueue('dlx_queue', { durable: true });
+channel.bindQueue('dlx_queue', 'dlx_exchange', 'dlx_routing_key');
+
+channel.assertQueue('task_queue', {
+  durable: true,
+  arguments: {
+    'x-dead-letter-exchange': 'dlx_exchange',
+    'x-dead-letter-routing-key': 'dlx_routing_key'
+  }
+});
+```
+
+> [!IMPORTANT]
+> **Constraint:** Always configure a DLX for business-critical queues to capture unprocessable messages for manual review or automated retry pipelines.
+
+### 🚀 Solution
+MANDATORY: Bind queues to a Dead Letter Exchange (DLX) using `x-dead-letter-exchange` arguments to handle failed messages deterministically.
+
+## 2. 🛑 Unbounded Queue Growth (No TTL/Max Length)
+### ❌ Bad Practice
+```javascript
+channel.assertQueue('log_queue', { durable: false });
+```
+### ⚠️ Problem
+Allowing unbounded queue growth during consumer outages or traffic spikes WILL exhaust broker memory and crash the RabbitMQ node, leading to cluster-wide failure.
+### ✅ Best Practice
+```javascript
+channel.assertQueue('log_queue', {
+  durable: true,
+  arguments: {
+    'x-max-length': 10000,
+    'x-overflow': 'reject-publish'
+  }
+});
+```
+
+> [!NOTE]
+> Ensure producers handle `reject-publish` errors gracefully when queues hit their limits.
+
+### 🚀 Solution
+Apply strict limits to queues (e.g., `x-max-length`, `x-message-ttl`) and configure `x-overflow` policies to protect the broker's memory footprint.

backend/readme.md

@@ -46,6 +46,7 @@ This folder acts as a container for documentation around the following backend t
 - [MongoDB](./mongodb/readme.md)
 - [Redis](./redis/readme.md)
 - [Microservices](./microservices/readme.md)
+- [RabbitMQ](./rabbitmq/readme.md)
 
 ---
 ## 1. 🛑 Global Domain Bleeding

backend/redis/security-best-practices.md

@@ -20,7 +20,7 @@ const redis = require('redis');
 const client = redis.createClient({ host: '127.0.0.1', port: 6379 }); // No authentication
 ```
 ### ⚠️ Problem
-Exposing Redis without authentication or encryption allows any connected client to read and write data, causing severe data breaches.
+Exposing Redis without authentication or encryption allows ALL connected clients to read and write data, causing severe data breaches.
 ### ✅ Best Practice
 ```javascript
 const redis = require('redis');