Output preview backend-architecture.preview

---
name: backend-architecture
description: > Use when this capability is needed. You are a senior backend architect. Help the user design…
category: other
runtime: Node.js / Python
---

# backend-architecture output preview

## PART A: Task fit
- Use case: > Use when this capability is needed. You are a senior backend architect. Help the user design, evaluate, or review backend service architecture with structured reasoning and platform-specific guidance. runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Process / Step 1: Understand the Context / Step 2: Select Architecture Style” and do not present inference as author intent.

## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Use when this capability is needed. You are a senior backend architect. Help the user design, evaluate, or review backend service architecture with structured reasoning and platform-specific guidance. runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Process / Step 1: Understand the Context / Step 2: Select Architecture Style” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.

## Running Rules
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.

Choose the trigger

The source mentions slash commands such as `/health`; use them first when your agent supports command triggers.

Provide inputs and boundaries

Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, read environment variables.

Validate with a small run

Start with a small task and check whether the result follows “Process / Step 1: Understand the Context / Step 2: Select Architecture Style”. Inspect diffs, logs, previews, or tests before expanding scope.

Review before delivery

Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.

SKILL.md SKILL.md

---
name: backend-architecture
description: > Use when this capability is needed. You are a senior backend architect. Help the user design…
category: other
source: tomevault-io/skills-registry
---

# backend-architecture

## When to use
- > Use when this capability is needed. You are a senior backend architect. Help the user design, evaluate, or review ba…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.

## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.

## Execution rules
- Organize steps around “Process / Step 1: Understand the Context / Step 2: Select Architecture Style” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.

## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.

Evidence boundary and execution chain

The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.

skill "backend-architecture" {
  input      -> user goal + target files + boundaries + acceptance criteria
  context    -> Process / Step 1: Understand the Context / Step 2: Select Architecture Style
  rules      -> SKILL.md triggers / order / output contract
  runtime    -> Node.js / Python | read files, write/modify files, read environment variables | mostly runs locally
  guardrails -> usually needs no extra API key + small-sample validation + diff/log review
  output     -> copyable result + checklist + next iteration
}

Question	Why It Matters
What does the service do?	Defines domain boundaries and API surface
What is the expected scale? (RPS, data volume, users)	Determines architecture complexity
What is the team size and experience?	Pragmatic technology selection
What are the integration points? (databases, queues, external APIs)	Shapes infrastructure design
What are the non-functional requirements? (latency, availability, compliance)	Drives architecture decisions
Is this greenfield or extending an existing system?	Migration vs. clean-slate

Style	Best For	Complexity	Team Size
Modular monolith	Most new services, unclear domain boundaries	Low-Medium	1-10
Microservices	Well-understood domains, independent deploy needs, large org	High	10+
Serverless (functions)	Event-driven, sporadic traffic, glue logic	Low	1-5
CQRS + Event Sourcing	Audit-heavy, complex domain, high-read scalability	Very High	5+
Hexagonal / Ports & Adapters	Long-lived services, high testability needs	Medium	Any

Concern	Recommended Approach
Dependency injection	Spring IoC (constructor injection preferred)
REST API	Spring MVC or Spring WebFlux (reactive)
Persistence	Spring Data JPA (relational) or Spring Data R2DBC (reactive)
Validation	Jakarta Bean Validation (`@Valid`, custom validators)
Security	Spring Security with JWT or OAuth2 Resource Server
Async / messaging	Spring Kafka, Spring AMQP, or Spring Cloud Stream
Caching	Spring Cache abstraction + Redis or Caffeine
Scheduling	`@Scheduled` or Spring Batch for complex jobs
API docs	SpringDoc OpenAPI (Swagger)
Testing	JUnit 5 + Mockito + Testcontainers for integration

Concern	Recommended Approach
Framework	NestJS (structured) or Fastify (performance) or Express (simple)
Validation	class-validator + class-transformer (NestJS) or Zod (Fastify/Express)
ORM	Prisma (type-safe, modern) or TypeORM or Drizzle
Auth	Passport.js or custom JWT middleware
Messaging	BullMQ (Redis queues) or Kafka.js
Caching	ioredis or node-cache
Testing	Jest or Vitest + Supertest for integration
API docs	@nestjs/swagger or express-openapi

Concern	Recommended Approach
Framework	FastAPI (modern, async) or Django (batteries-included)
ORM	SQLAlchemy 2.0 (FastAPI) or Django ORM
Validation	Pydantic v2 (FastAPI) or Django serializers
Auth	FastAPI Security or Django Auth + DRF
Task queue	Celery + Redis or Dramatiq
Caching	Redis via aioredis or Django cache framework
Testing	pytest + httpx (async) or Django TestCase

backend-architecture

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Backend Architecture Design & Review

Process

Step 1: Understand the Context

Step 2: Select Architecture Style

Step 3: Apply Platform-Specific Patterns

Spring Boot (Java / Kotlin)

Node.js (Express / NestJS / Fastify)

Python (Django / FastAPI)

Go

Step 4: Design the Data Layer

Step 5: Design Cross-Cutting Concerns

Output Format

Quality Checklist

Edge Cases

Discussion

Concern	Recommended Approach
HTTP	Standard library `net/http` + chi or Echo or Gin
Persistence	sqlc (SQL-first) or GORM or Ent
Validation	go-playground/validator
Auth	JWT middleware (custom or framework-provided)
Messaging	Sarama (Kafka) or AMQP
DI	Wire (compile-time) or manual constructor injection
Testing	Standard `testing` package + testify + testcontainers-go

Decision	Options	Guidance
Database	PostgreSQL (default), MySQL, MongoDB, DynamoDB	PostgreSQL unless you have a specific reason not to
ORM vs. raw SQL	ORM for CRUD-heavy, raw SQL for complex queries	Use both — ORM for simple ops, raw for performance-critical
Migration	Flyway/Liquibase (Java), Alembic (Python), Prisma Migrate, golang-migrate	Always version-controlled, always forward-only
Connection pooling	HikariCP (Java), pgBouncer, built-in (Go)	Size pool to match expected concurrency
Caching	Redis (distributed), Caffeine/in-process (local)	Cache reads, invalidate on writes, set TTLs

Concern	Implementation
Error handling	Consistent error response format, domain exceptions mapped to HTTP codes
Logging	Structured JSON logs, correlation IDs, log levels (no PII in logs)
Observability	OpenTelemetry traces + Prometheus metrics + structured logs
Health checks	`/health/live` (process alive) + `/health/ready` (dependencies ready)
Configuration	Environment variables, validated at startup, no secrets in code
Rate limiting	Per-client or per-endpoint, 429 with Retry-After header
Graceful shutdown	Drain in-flight requests, close DB connections, stop consumers