backend-design

Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.

16 stars

Best use case

backend-design is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.

Teams using backend-design should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/backend-design/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/development/backend-design/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/backend-design/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How backend-design Compares

Feature / Agentbackend-designStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Elite Tier Backend standards, including Vertical Slice Architecture, Zero Trust Security, and High-Performance API protocols.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

<domain_overview>
# Backend Design System

> **Philosophy:** The Backend is the Fortress. Logic is Law. Latency is the Enemy.
> **Core Principle:** ISOLATE features. TRUST no one. SCALE linearly.

**ANTI-HAPPY PATH MANDATE (CRITICAL):** Never assume the ideal scenario. AI-generated code often fails by ignoring edge cases and failure modes. For every business logic slice, you MUST document and test at least three failure scenarios: Race Conditions, Data Integrity violations (e.g., unique constraint overlaps), and Boundary failures. Reject any implementation that only covers the 'Happy Path'. Engineering is the art of handling what shouldn't happen.
</domain_overview>

<architectural_protocols>
## 🚀 ELITE TIER KNOWLEDGE (ARCHITECTURAL PROTOCOLS)

### 0. The "Vertical Slice" Law (The Anti-Layer Mandate)
> **CRITICAL:** You are FORBIDDEN from creating "Horizontal Layers" (Controllers, Services, Repositories) as primary folders.

**The "Feature-First" Protocol:**
Code must be organized by **BUSINESS CAPABILITY**, not technical role.
1.  **The Slice:** A single directory (e.g., `features/create-order/`) contains EVERYTHING needed for that feature:
    *   `handler.ts` (Controller)
    *   `logic.ts` (Domain/Service)
    *   `schema.ts` (DTO/Validation)
    *   `db.ts` (Data Access)
2.  **The Benefit:** Changing a feature requires touching only ONE folder. No "Shotgun Surgery" across 5 layers.
3.  **Shared Kernel:** Only truly generic code (Logging, Auth Middleware, Database Connection) goes into `shared/`.

### 1. The "Modular Monolith" Mandate
*   **Microservices Ban:** Do NOT start with microservices. Start with a **Modular Monolith**.
*   **Modulith Rules:**
    *   Modules must be isolated (like internal microservices).
    *   Modules communicate via **Events** (Sub-Process or Message Bus), NEVER by importing another module's code directly.
    *   **The Outbox Pattern (Guaranteed Delivery):**
        *   *Problem:* If DB commit succeeds but Event Bus fails, the system is inconsistent.
        *   *Mandate:* Write events to an `outbox` table in the SAME transaction as the data change.
        *   *Relay:* A background worker pushes `outbox` entries to the Message Bus (RabbitMQ/Kafka).
    *   Data Sovereignty: Module A cannot query Module B's tables. It must ask Module B via API/Event.

### 2. The "Zero Trust" Security Protocol
> **Detailed protocols:** See [security-protocols.md](security-protocols.md)

**Quick Rules:**
1. **Strict Serialization:** NEVER return raw DB entities → Use ResponseDTO
2. **Validation at Gate:** Schema validation (Zod/Pydantic) BEFORE logic
3. **Token Sovereignty:** PASETO v4 > JWT (Ed25519 if JWT forced)
</architectural_protocols>

<reliability_contracts>
## 🏗️ Reliability & Performance Contracts

### 3. The "Sub-100ms" Performance Mandate
*   **The Latency Budget:** P50 < 100ms. P99 < 500ms.
*   **UUIDv7 (The Time-Lord Rule):**
    *   *Ban:* Never use `UUIDv4` (Random) for Primary Keys. It fragments B-Tree indexes.
    *   *Mandate:* Use **UUIDv7** (Time-ordered). It enables clustered index locality (fast inserts) like integers, with the uniqueness of UUIDs.
*   **N+1 Assassin:**
    *   *Check:* Always inspect ORM queries. Loops triggering DB calls are a "Level 0" error.
    *   *Fix:* Use `DataLoader` pattern or explicit `JOIN` loading.

### 4. API Reliability Contracts
*   **RFC 7807 (Problem Details):**
    *   *Ban:* returning `{ "error": "Something went wrong" }`.
    *   *Mandate:* Return standard Problem JSON:
        ```json
        {
          "type": "https://api.myapp.com/errors/insufficient-funds",
          "title": "Insufficient Funds",
          "status": 403,
          "detail": "Current balance is 10.00, required is 15.00",
          "instance": "/transactions/12345"
        }
        ```
*   **Idempotency Keys:**
    *   *Rule:* All critical `POST/PATCH` (Money, State Change) must accept an `Idempotency-Key` header.
    *   *Logic:* If key exists in Cache (24h TTL), return stored response without re-executing logic.
</reliability_contracts>

<database_integrity>
## 🗄️ Database Integrity & Design

### 5. Database Integrity & Design
*   **Hard Constraints:** Application-level checks are "Suggestions". Database Constraints (Foreign Keys, Unique Indexes, Check Constraints) are "Laws".
*   **Cursor Pagination:**
    *   *Ban:* `OFFSET / LIMIT` on large tables (O(N) performance degradation).
    *   *Mandate:* Cursor-based pagination (`WHERE created_at < cursor LIMIT 20`).
*   **Migration Discipline:**
    *   Never alter a column in a way that locks the table for >1s.
    *   Use "Expand and Contract" pattern for breaking changes.
*   **Concurrency Control:**
    *   *Problem:* Two users update the same record. The last one wipes the first.
    *   *Mandate:* Use Optimistic Locking. Add a `version` (int) column.
    *   *Logic:* Update WHERE `id` = X AND `version` = Y. If 0 rows affected, throw `StaleObjectException`.

### 6. AI & Vector Readiness
*   **Semantic Storage:** Backend must be ready to store embeddings (Vector Types).
*   **Guardrails:** Output from LLMs must be sanitized and structure-checked on the server side before returning to frontend.
</database_integrity>

<observability>
## 👁️ Observability & Monitoring (The "Glass Box" Protocol)

### 7. Structured Logging Only
*   **Ban:** `console.log("User updated")`. String logs are useless for machines.
*   **Mandate:* JSON Logs with correlation IDs. `{ "level": "info", "event": "user_updated", "user_id": "u7-...", "trace_id": "..." }`.

### 8. Distributed Tracing (OpenTelemetry)
*   Every request MUST carry a `traceparent` header.
*   Spans must cover: DB Queries, External API Calls, and Redis operations.

### 9. Health Checks
*   Liveness (`/health/live`): "Am I running?" (Instant, no checks).
*   Readiness (`/health/ready`): "Can I take traffic?" (Check DB/Redis connection).
</observability>

<resilience>
## 🛡️ Resilience Patterns (The "Anti-Fragile" Mandate)

### 10. Circuit Breakers
*   Wrap ALL external calls (Payment Gateways, 3rd Party APIs) in a Circuit Breaker.
*   *Logic:* After 5 failures, fail fast for 30s. Don't drown the downstream service.

### 11. Rate Limiting
*   Protect *every* public endpoint with a Token Bucket rate limiter (Redis-backed).
*   Differentiate limits by User Role (Anon: 60/min, Pro: 1000/min).
</resilience>

<workflow_rules>
## 🔧 Workflow Rules

### 1. The Pre-Flight Checklist
0.  **Environment Hardening:**
    *   Verify all `process.env` variables at startup using a schema (e.g., `t3-env` or `envalid`). If a key is missing, crash immediately. Do not start the server in an undefined state.
Before writing a single handler:
1.  **Define the DTOs:** Request Schema (Zod) and Response Schema.
2.  **Define the Error States:** What can go wrong? (404, 409, 429).
3.  **Define the Data Access:** What is the most efficient SQL query?

### 2. The "No Magic" Rule
*   Avoid "Magical" ORM features (Lazy Loading, Auto-Saving context).
*   Prefer Explicit over Implicit. "Write the SQL (or Query Builder) if the ORM hides expensive logic."

### 3. Testing Pyramid
1.  **Unit:** Test Domain Logic in isolation (mock DB).
2.  **Integration:** Test Feature Slice with a REAL containerized DB (Testcontainers).
3.  **E2E:** Test critical flows from the "Outside".
</workflow_rules>

<audit_and_reference>
## 📂 Cognitive Audit Cycle
Before committing code:
1.  **Is the endpoint under a feature slice?** (Not in a generic controller folder).
2.  **Is Input Validated with a Schema?** (Zero Trust).
3.  **Are DB Indexes used?** (Run `EXPLAIN ANALYZE`).
4.  **Is the Primary Key UUIDv7?** (Index Perf).
5.  **Are secrets managed properly?** (No hardcoded strings).

---

## 🔗 CROSS-SKILL INTEGRATION

| Skill | Backend Adds... |
|-------|-----------------|
| `@frontend-design` | API contracts, CORS config, error responses |
| `@clean-code` | Input validation, no raw SQL, dependency security |
| `@tdd-mastery` | Integration tests with Testcontainers |
| `@planning-mastery` | API endpoint task breakdown |
| `@debug-mastery` | Structured logging, distributed tracing |

> **Command:** Use these skills to architect "Fortress-Level" backend systems.
</audit_and_reference>

Related Skills

backend-patterns

16
from diegosouzapw/awesome-omni-skill

Backend patterns for ORPC routers, Drizzle schemas, and server-side code. Use when creating API endpoints, database tables, or services.

backend-passport-js

16
from diegosouzapw/awesome-omni-skill

Authentication middleware for Express.js and Node.js applications. Use when building Express APIs that need JWT authentication, OAuth, or custom auth strategies. Provides 500+ authentication strategies. Choose Passport.js over Auth.js for Express backends, pure API servers, or when you need maximum control over auth flow.

backend-nodejs

16
from diegosouzapw/awesome-omni-skill

Node.js/TypeScript backend expert. Handles Express/Fastify API routes, TypeScript strict mode, Prisma ORM, Zod validation, error handling, configuration management. Use when project is Node.js backend (package.json + TypeScript server).

Backend Node.js Expert

16
from diegosouzapw/awesome-omni-skill

专注于 Node.js 后端开发模式与最佳实践。

Backend Migrations

16
from diegosouzapw/awesome-omni-skill

Create and manage database schema migrations with reversible operations, zero-downtime deployments, and safe rollback strategies. Use this skill when writing database migrations for PostgreSQL, MySQL, SQLite, MongoDB, or any database system; when using ORMs like Prisma, Sequelize, TypeORM, ActiveRecord, Django ORM, or similar migration tools; when implementing schema changes (adding tables, columns, indexes, constraints); when performing data migrations or transformations; when creating indexes on large tables with concurrent options to avoid locks; when separating schema changes from data migrations for safer rollbacks; when implementing zero-downtime deployment strategies for high-availability systems; when versioning database schemas and managing migration order; or when working with database change management in production environments.

backend

16
from diegosouzapw/awesome-omni-skill

Skill para diseñar y construir backends y APIs **modulares**, **auditables**, **resilientes** y **multi-tenant**, con seguridad fuerte, modelado correcto (incl. ledger cuando aplique), datos y jobs/colas operables.

backend-guidelines

16
from diegosouzapw/awesome-omni-skill

Comprehensive backend development guide for Node.js/Express/TypeScript microservices. Use when creating routes, controllers, services, repositories, middleware, or working with Express APIs, Prisma database access, Sentry error tracking, Zod validation, unifiedConfig, dependency injection, or async patterns. Covers layered architecture (routes → controllers → services → repositories), BaseController pattern, error handling, performance monitoring, testing strategies, and migration from legacy patterns.

backend-guide

16
from diegosouzapw/awesome-omni-skill

Complete backend development guide covering Node.js, Python, Go, Java, PHP, databases, APIs, authentication, and server architecture. Use when building server applications, APIs, or backend systems.

Backend Expert Pro

16
from diegosouzapw/awesome-omni-skill

A complete back-end specialist skill for designing scalable architectures, robust APIs, and secure server-side systems.

backend-expert-advisor

16
from diegosouzapw/awesome-omni-skill

Backend expert guidance for API/DB/Security/Architecture

backend-development

16
from diegosouzapw/awesome-omni-skill

Build robust backend systems with modern technologies (Node.js, Python, Go, Rust), frameworks (NestJS, FastAPI, Django), databases (PostgreSQL, MongoDB, Redis), APIs (REST, GraphQL, gRPC), authentication (OAuth 2.1, JWT), testing strategies, security best practices (OWASP Top 10), performance optimization, scalability patterns (microservices, caching, sharding), DevOps practices (Docker, Kubernetes, CI/CD), and monitoring. Use when designing APIs, implementing authentication, optimizing database queries, setting up CI/CD pipelines, handling security vulnerabilities, building microservices, or developing production-ready backend systems.

backend-development-tdd-orchestrator

16
from diegosouzapw/awesome-omni-skill

Master TDD orchestrator specializing in red-green-refactor discipline, multi-agent workflow coordination, and comprehensive test-driven development practices. Enforces TDD best practices across teams with AI-assisted testing and modern frameworks. Use PROACTIVELY for TDD implementation and governance. Use when: the task directly matches tdd orchestrator responsibilities within plugin backend-development. Do not use when: a more specific framework or task-focused skill is clearly a better match.