diff --git a/backend/expressjs/architecture.md b/backend/expressjs/architecture.md new file mode 100644 index 0000000..001abe9 --- /dev/null +++ b/backend/expressjs/architecture.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Express.js within the backend domain. +technology: Express.js +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Express.js Architecture +vibe_coding_ready: true +version: "4.x / 5.x" +tags: [best-practices, clean-code, expressjs, vibe-coding, cursor-rules, javascript, typescript, software-architecture, system-design, mvc, production-ready, programming-standards, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, enterprise-patterns, backend] +ai_role: Senior Express.js Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🏗️ Express.js Architecture Best Practices diff --git a/backend/expressjs/readme.md b/backend/expressjs/readme.md index 3c3de65..0af884d 100644 --- a/backend/expressjs/readme.md +++ b/backend/expressjs/readme.md @@ -29,6 +29,41 @@ last_updated: 2026-03-23 --- + +## 🔄 Architecture Data Flow + +```mermaid +sequenceDiagram + participant Client + participant Router as Express Router + participant AuthMW as Auth Middleware + participant ValMW as Validation Middleware + participant Controller as Controller + participant Service as Service Layer + participant ErrorMW as Global Error Handler + + Client->>Router: HTTP Request + Router->>AuthMW: Authenticate + AuthMW-->>Router: Authorized + Router->>ValMW: Validate Request + ValMW-->>Router: Validated + Router->>Controller: Route Request + Controller->>Service: Execute Logic + + alt Success + Service-->>Controller: Return Result + Controller-->>Client: HTTP Response + else Failure + Service-->>ErrorMW: Throw Error + ErrorMW-->>Client: Standardized Error Response + end +``` + +## 📚 Specialized Documentation +- [architecture.md](./architecture.md) +- [security-best-practices.md](./security-best-practices.md) + +--- ## 1. Controller / Route Decoupling ### ❌ Bad Practice ```javascript diff --git a/backend/expressjs/security-best-practices.md b/backend/expressjs/security-best-practices.md new file mode 100644 index 0000000..e8fe31e --- /dev/null +++ b/backend/expressjs/security-best-practices.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Express.js Security within the backend domain. +technology: Express.js +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Express.js Security +vibe_coding_ready: true +version: "4.x / 5.x" +tags: [best-practices, clean-code, security-patterns, vibe-coding, cursor-rules, expressjs, software-architecture, system-design, solid-principles, production-ready, programming-standards, node-js, security, scalable-code, windsurf-rules, ai-coding, enterprise-patterns] +ai_role: Senior Express.js Security Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🔒 Express.js Security Best Practices diff --git a/backend/microservices/api-design.md b/backend/microservices/api-design.md new file mode 100644 index 0000000..a9edafd --- /dev/null +++ b/backend/microservices/api-design.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Microservices API Design within the backend domain. +technology: Microservices +domain: backend +level: Architect +complexity: Architect +topic: Microservices API Design +vibe_coding_ready: true +version: Agnostic +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, microservices, distributed-systems, system-design, solid-principles, production-ready, scalable-code] +ai_role: Senior Microservices Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🧩 Microservices API Design diff --git a/backend/microservices/architecture.md b/backend/microservices/architecture.md new file mode 100644 index 0000000..fa8c3b3 --- /dev/null +++ b/backend/microservices/architecture.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Microservices Architecture within the backend domain. +technology: Microservices +domain: backend +level: Architect +complexity: Architect +topic: Microservices Architecture +vibe_coding_ready: true +version: Agnostic +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, microservices, distributed-systems, system-design, solid-principles, production-ready, scalable-code] +ai_role: Senior Microservices Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🧩 Microservices Architecture diff --git a/backend/microservices/readme.md b/backend/microservices/readme.md new file mode 100644 index 0000000..673be9c --- /dev/null +++ b/backend/microservices/readme.md @@ -0,0 +1,93 @@ +--- +description: Vibe coding guidelines and architectural constraints for Microservices within the backend domain. +technology: Microservices +domain: backend +level: Architect +complexity: Architect +topic: Microservices +vibe_coding_ready: true +version: Agnostic +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, microservices, distributed-systems, system-design, solid-principles, production-ready, scalable-code] +ai_role: Senior Microservices Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +
+ Microservices Logo + + # 🧩 Microservices Production-Ready Best Practices +
+ +--- + +This document establishes **best practices** for designing and maintaining a Microservices architecture. These constraints guarantee a scalable, highly secure, and clean system suitable for an enterprise-level, production-ready backend. + +# ⚙️ Context & Scope +- **Primary Goal:** Provide an uncompromising set of rules and architectural constraints for distributed system environments. +- **Target Tooling:** AI-agents (Cursor, Windsurf, Copilot, Antigravity) and System Architects. +- **Tech Stack Version:** Agnostic + +> [!IMPORTANT] +> **Architectural Standard (Contract):** Ensure loose coupling and high cohesion. Each microservice must own its domain data. Use asynchronous messaging (e.g., Kafka, RabbitMQ) for inter-service communication to prevent cascading failures. + +--- + +## 🏗️ 1. Architecture & Design + +### Domain-Driven Design (DDD) +- Define clear Bounded Contexts for every service to avoid spaghetti dependencies. +- Implement the API Gateway pattern to route external requests to internal microservices, handling cross-cutting concerns (auth, rate limiting). + +### 🔄 Data Flow Lifecycle + +```mermaid +sequenceDiagram + participant Client + participant Gateway as API Gateway + participant Auth as Auth Service + participant User as User Service + participant Msg as Message Broker (Kafka) + participant Notification as Notification Service + + Client->>Gateway: POST /users (Create User) + Gateway->>Auth: Validate Token + Auth-->>Gateway: Token Valid + Gateway->>User: Create User Request + User-->>User: Persist User to DB + User->>Msg: Publish "UserCreated" Event + User-->>Gateway: Return 201 Created + Gateway-->>Client: Respond with Success + + Msg->>Notification: Consume "UserCreated" Event + Notification-->>Notification: Send Welcome Email +``` + +## 🔒 2. Security Best Practices + +### Service-to-Service Authentication +- Implement Zero Trust architecture. Internal services must authenticate each other using mTLS (Mutual TLS) or signed JWTs. +- Secrets must never be hardcoded. Utilize a secret manager (HashiCorp Vault, AWS Secrets Manager). + +### Data Isolation +- Enforce "Database per Service" pattern. Services must never share a single database to ensure independent scaling and deployment. + +## 🚀 3. Reliability Optimization + +### Resilience Patterns +- Implement Circuit Breakers (e.g., resilience4j) to fail fast and recover when a dependent service goes down. +- Implement retries with exponential backoff for transient network errors. +- Ensure Idempotency for critical operations to handle duplicated requests gracefully. + +### Observability +- Distributed Tracing is mandatory (OpenTelemetry). All requests must pass a Correlation ID across service boundaries. +- Centralized Logging (ELK, Datadog) is required for debugging complex distributed issues. + +## 📚 Specialized Documentation +- [architecture.md](./architecture.md) +- [security-best-practices.md](./security-best-practices.md) +- [api-design.md](./api-design.md) + +--- + +[Back to Top](#) diff --git a/backend/microservices/security-best-practices.md b/backend/microservices/security-best-practices.md new file mode 100644 index 0000000..26791c8 --- /dev/null +++ b/backend/microservices/security-best-practices.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Microservices Security within the backend domain. +technology: Microservices +domain: backend +level: Architect +complexity: Architect +topic: Microservices Security +vibe_coding_ready: true +version: Agnostic +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, microservices, distributed-systems, system-design, solid-principles, production-ready, scalable-code] +ai_role: Senior Microservices Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🧩 Microservices Security Best Practices diff --git a/backend/nestjs/architecture.md b/backend/nestjs/architecture.md new file mode 100644 index 0000000..3c78f05 --- /dev/null +++ b/backend/nestjs/architecture.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for NestJS within the backend domain. +technology: NestJS +domain: backend +level: Senior/Architect +complexity: Advanced +topic: NestJS Architecture +vibe_coding_ready: true +version: "11+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, react-best-practices, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, fsd, ddd, enterprise-patterns] +ai_role: Senior NestJS Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🏗️ NestJS 11+ Architecture Best Practices diff --git a/backend/nestjs/readme.md b/backend/nestjs/readme.md index a5cb62a..e6862e4 100644 --- a/backend/nestjs/readme.md +++ b/backend/nestjs/readme.md @@ -3,7 +3,7 @@ description: Vibe coding guidelines and architectural constraints for NestJS wit technology: NestJS domain: backend level: Senior/Architect -version: "10+" +version: "11+" tags: [best-practices, clean-code, architecture-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, react-best-practices, node-js, design-patterns, scalable-code, windsurf-rules, ai-coding, fsd, ddd, enterprise-patterns] ai_role: Senior NestJS Architecture Expert last_updated: 2026-03-23 @@ -22,13 +22,46 @@ last_updated: 2026-03-23 ## 🎯 Context & Scope - **Primary Goal:** Предоставить строгие архитектурные правила и 30 паттернов разработки на NestJS. - **Target Tooling:** AI-агенты (Cursor, Windsurf, Copilot) и Senior-разработчики. -- **Tech Stack Version:** NestJS 10+ +- **Tech Stack Version:** NestJS 11+ > [!IMPORTANT] > **Архитектурный стандарт (Contract):** Используйте строгую типизацию TypeScript, DI (Dependency Injection) и модульную структуру. Бизнес-логика должна быть изолирована от деталей HTTP-уровня и баз данных. --- + +## 🔄 Architecture Data Flow + +```mermaid +sequenceDiagram + participant Client + participant Controller as Controller (Thin) + participant Pipe as ValidationPipe (Global) + participant Guard as AuthGuard + participant Service as Service (Fat) + participant Repo as Repository (Port) + participant DB as Database + + Client->>Controller: HTTP Request + Controller->>Guard: Check Authorization + Guard-->>Controller: Authorized + Controller->>Pipe: Validate DTO + Pipe-->>Controller: Validated + Controller->>Service: Execute Business Logic + Service->>Repo: Fetch/Save Data + Repo->>DB: Query + DB-->>Repo: Data + Repo-->>Service: Domain Entity + Service-->>Controller: Result (mapped to DTO) + Controller-->>Client: HTTP Response +``` + + +## 📚 Specialized Documentation +- [architecture.md](./architecture.md) +- [security-best-practices.md](./security-best-practices.md) + +--- ### 🚨 1. Clean Architecture Modules (Изоляция логики) #### ❌ Bad Practice ```typescript diff --git a/backend/nestjs/security-best-practices.md b/backend/nestjs/security-best-practices.md new file mode 100644 index 0000000..fcde639 --- /dev/null +++ b/backend/nestjs/security-best-practices.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for NestJS Security within the backend domain. +technology: NestJS +domain: backend +level: Senior/Architect +complexity: Advanced +topic: NestJS Security +vibe_coding_ready: true +version: "11+" +tags: [best-practices, clean-code, security-patterns, vibe-coding, cursor-rules, typescript, software-architecture, system-design, solid-principles, production-ready, programming-standards, node-js, security, scalable-code, windsurf-rules, ai-coding, enterprise-patterns] +ai_role: Senior NestJS Security Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🔒 NestJS 11+ Security Best Practices diff --git a/backend/postgresql/architecture.md b/backend/postgresql/architecture.md new file mode 100644 index 0000000..80e63dd --- /dev/null +++ b/backend/postgresql/architecture.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for PostgreSQL Architecture within the backend domain. +technology: PostgreSQL +domain: backend +level: Senior/Architect +complexity: Advanced +topic: PostgreSQL Architecture +vibe_coding_ready: true +version: "16+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, postgresql, database, sql, rdbms, system-design, production-ready, scalable-code] +ai_role: Senior PostgreSQL Database Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🐘 PostgreSQL Architecture diff --git a/backend/postgresql/database-optimization.md b/backend/postgresql/database-optimization.md new file mode 100644 index 0000000..fe1c164 --- /dev/null +++ b/backend/postgresql/database-optimization.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for PostgreSQL Optimization within the backend domain. +technology: PostgreSQL +domain: backend +level: Senior/Architect +complexity: Advanced +topic: PostgreSQL Optimization +vibe_coding_ready: true +version: "16+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, postgresql, database, sql, rdbms, system-design, production-ready, scalable-code] +ai_role: Senior PostgreSQL Database Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🐘 PostgreSQL Database Optimization diff --git a/backend/postgresql/readme.md b/backend/postgresql/readme.md new file mode 100644 index 0000000..2a9a547 --- /dev/null +++ b/backend/postgresql/readme.md @@ -0,0 +1,87 @@ +--- +description: Vibe coding guidelines and architectural constraints for PostgreSQL within the backend domain. +technology: PostgreSQL +domain: backend +level: Senior/Architect +complexity: Advanced +topic: PostgreSQL +vibe_coding_ready: true +version: "16+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, postgresql, database, sql, rdbms, system-design, production-ready, scalable-code] +ai_role: Senior PostgreSQL Database Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +
+ PostgreSQL Logo + + # 🐘 PostgreSQL Production-Ready Best Practices +
+ +--- + +This document establishes **best practices** for building and maintaining PostgreSQL databases. These constraints guarantee a scalable, highly secure, and clean architecture suitable for an enterprise-level, production-ready backend. + +# ⚙️ Context & Scope +- **Primary Goal:** Provide an uncompromising set of rules and architectural constraints for PostgreSQL environments. +- **Target Tooling:** AI-agents (Cursor, Windsurf, Copilot, Antigravity) and Senior Database Administrators. +- **Tech Stack Version:** PostgreSQL 16+ + +> [!IMPORTANT] +> **Architectural Standard (Contract):** Use strict data types, enforce referential integrity, and optimize queries with appropriate indexing. Avoid business logic in stored procedures unless strictly necessary for performance. + +--- + +## 🏗️ 1. Architecture & Design + +### Database Schema Design +- **Normalized by Default:** Start with 3NF (Third Normal Form) to minimize redundancy. +- **Denormalize for Read Performance:** Selectively denormalize where read heavy workloads require optimization, utilizing Materialized Views. +- **Primary Keys:** Use `UUIDv7` or `BIGINT IDENTITY` (PostgreSQL 10+) for primary keys over sequential `SERIAL`. + +### 🔄 Data Flow Lifecycle + +```mermaid +sequenceDiagram + participant App as Application Layer + participant Pool as Connection Pooler (PgBouncer) + participant DB as PostgreSQL Database + + App->>Pool: Request Database Connection + Pool-->>App: Provide Connection from Pool + App->>DB: Execute Parameterized Query + DB-->>App: Return Result Set + App->>Pool: Release Connection +``` + +## 🔒 2. Security Best Practices + +### Connection Security +- Enforce SSL/TLS for all database connections. +- Utilize a connection pooler like PgBouncer for performance and connection limit management. + +### Access Control +- Principle of Least Privilege (PoLP): Create specific database roles for different application services. Never use the `postgres` superuser for application access. +- Implement Row-Level Security (RLS) for multi-tenant applications to isolate data at the database layer. + +## 🚀 3. Performance Optimization + +### Indexing Strategies +- Use B-Tree indexes for equality and range queries. +- Implement GIN/GiST indexes for Full-Text Search and JSONB fields. +- Avoid over-indexing, as it degrades write performance. Monitor unused indexes and remove them. + +### Query Optimization +- Explicit DB queries required: Never use `SELECT *`. Only select the specific columns needed. +- Utilize `EXPLAIN ANALYZE` to identify query bottlenecks. +- Implement pagination using keyset pagination (cursor-based) instead of `OFFSET`/`LIMIT` for large datasets. + +## 📚 Specialized Documentation +- [architecture.md](./architecture.md) +- [security-best-practices.md](./security-best-practices.md) +- [database-optimization.md](./database-optimization.md) + +--- + +[Back to Top](#) diff --git a/backend/postgresql/security-best-practices.md b/backend/postgresql/security-best-practices.md new file mode 100644 index 0000000..9d07fa1 --- /dev/null +++ b/backend/postgresql/security-best-practices.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for PostgreSQL Security within the backend domain. +technology: PostgreSQL +domain: backend +level: Senior/Architect +complexity: Advanced +topic: PostgreSQL Security +vibe_coding_ready: true +version: "16+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, postgresql, database, sql, rdbms, system-design, production-ready, scalable-code] +ai_role: Senior PostgreSQL Database Architect +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🐘 PostgreSQL Security Best Practices diff --git a/backend/readme.md b/backend/readme.md index 2677cdd..6b3343c 100644 --- a/backend/readme.md +++ b/backend/readme.md @@ -43,3 +43,6 @@ This folder acts as a container for documentation around the following backend t - [NestJS](./nestjs/readme.md) - [ExpressJS](./expressjs/readme.md) - [Node.js](./nodejs/readme.md) +- [PostgreSQL](./postgresql/readme.md) +- [Redis](./redis/readme.md) +- [Microservices](./microservices/readme.md) diff --git a/backend/redis/api-design.md b/backend/redis/api-design.md new file mode 100644 index 0000000..39e0f1a --- /dev/null +++ b/backend/redis/api-design.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Redis API Design within the backend domain. +technology: Redis +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Redis API Design +vibe_coding_ready: true +version: "7+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, redis, in-memory, nosql, system-design, production-ready, scalable-code] +ai_role: Senior Redis Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🟥 Redis API Design diff --git a/backend/redis/architecture.md b/backend/redis/architecture.md new file mode 100644 index 0000000..1292c5b --- /dev/null +++ b/backend/redis/architecture.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Redis Architecture within the backend domain. +technology: Redis +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Redis Architecture +vibe_coding_ready: true +version: "7+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, redis, in-memory, nosql, system-design, production-ready, scalable-code] +ai_role: Senior Redis Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🟥 Redis Architecture diff --git a/backend/redis/readme.md b/backend/redis/readme.md new file mode 100644 index 0000000..33a5211 --- /dev/null +++ b/backend/redis/readme.md @@ -0,0 +1,93 @@ +--- +description: Vibe coding guidelines and architectural constraints for Redis within the backend domain. +technology: Redis +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Redis +vibe_coding_ready: true +version: "7+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, redis, in-memory, nosql, system-design, production-ready, scalable-code] +ai_role: Senior Redis Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +
+ Redis Logo + + # 🟥 Redis Production-Ready Best Practices +
+ +--- + +This document establishes **best practices** for building and maintaining Redis data stores. These constraints guarantee a scalable, highly secure, and clean architecture suitable for an enterprise-level, production-ready backend. + +# ⚙️ Context & Scope +- **Primary Goal:** Provide an uncompromising set of rules and architectural constraints for Redis environments. +- **Target Tooling:** AI-agents (Cursor, Windsurf, Copilot, Antigravity) and Senior Backend Developers. +- **Tech Stack Version:** Redis 7+ + +> [!IMPORTANT] +> **Architectural Standard (Contract):** Utilize Redis primarily as a caching layer, session store, or message broker, not as a primary persistence database. Never use `KEYS *` in production. + +--- + +## 🏗️ 1. Architecture & Design + +### Cache Design +- **Cache-Aside Pattern:** Applications should read from the cache first; on a cache miss, read from the database, populate the cache, and return the result. +- **TTL Requirements:** Every cached key must have an expiration Time-To-Live (TTL) to prevent memory exhaustion and stale data. + +### 🔄 Data Flow Lifecycle + +```mermaid +sequenceDiagram + participant Client + participant App as Application Layer + participant Redis as Redis Cache + participant DB as Primary Database + + Client->>App: Request Data + App->>Redis: GET Cache Key + + alt Cache Hit + Redis-->>App: Return Cached Data + App-->>Client: Respond with Data + else Cache Miss + Redis-->>App: Return NULL + App->>DB: SELECT Data + DB-->>App: Return Source Data + App->>Redis: SETEX Cache Key with TTL + App-->>Client: Respond with Data + end +``` + +## 🔒 2. Security Best Practices + +### Connection Security +- Never expose Redis to the public internet. Ensure it is isolated within a private network. +- Enable requirepass to enforce password authentication. +- Rename dangerous commands (like `FLUSHALL`, `FLUSHDB`, `CONFIG`) in production to prevent accidental data loss. + +### Network Architecture +- Utilize TLS (Transport Layer Security) for encrypting data in transit. + +## 🚀 3. Performance Optimization + +### Command Usage +- Use pipelining to send multiple commands to the server without waiting for the replies, optimizing latency. +- Strictly avoid blocking operations like `KEYS *`, and `SMEMBERS` on large sets. Use `SCAN` and `SSCAN` for iteration. + +### Data Types +- Optimize data structure usage. Employ Hashes for objects to save memory, and Sorted Sets for leaderboards or rate limiting. +- Avoid large keys or values (keep them under 512MB, but ideally much smaller) to minimize network transfer and memory overhead. + +## 📚 Specialized Documentation +- [architecture.md](./architecture.md) +- [security-best-practices.md](./security-best-practices.md) +- [api-design.md](./api-design.md) + +--- + +[Back to Top](#) diff --git a/backend/redis/security-best-practices.md b/backend/redis/security-best-practices.md new file mode 100644 index 0000000..67d0161 --- /dev/null +++ b/backend/redis/security-best-practices.md @@ -0,0 +1,16 @@ +--- +description: Vibe coding guidelines and architectural constraints for Redis Security within the backend domain. +technology: Redis +domain: backend +level: Senior/Architect +complexity: Advanced +topic: Redis Security +vibe_coding_ready: true +version: "7+" +tags: [best-practices, clean-code, architecture-patterns, vibe-coding, redis, in-memory, nosql, system-design, production-ready, scalable-code] +ai_role: Senior Redis Architecture Expert +last_updated: 2026-03-27 +last_evolution: 2026-03-27 +--- + +# 🟥 Redis Security Best Practices