Software Backend Engineering
Use this skill to design, implement, and review production-grade backend services: API boundaries, data layer, auth, caching, observability, error handling, testing, and deployment.
Defaults to bias toward: type-safe boundaries (validation at the edge), OpenTelemetry for observability, zero-trust assumptions, idempotency for retries, RFC 9457 errors, Postgres + pooling, structured logs, timeouts, and rate limiting.
Quick Reference
| Task |
Default Picks |
Notes |
| REST API |
Fastify / Express / NestJS |
Prefer typed boundaries + explicit timeouts |
| Edge API |
Hono / platform-native handlers |
Keep work stateless, CPU-light |
| Type-Safe API |
tRPC |
Prefer for TS monorepos and internal APIs |
| GraphQL API |
Apollo Server / Pothos |
Prefer for complex client-driven queries |
| Database |
PostgreSQL |
Use pooling + migrations + query budgets |
| ORM / Query Layer |
Prisma / Drizzle / SQLAlchemy / GORM / SeaORM |
Prefer explicit transactions |
| Authentication |
OIDC/OAuth + sessions/JWT |
Prefer httpOnly cookies for browsers |
| Validation |
Zod / Pydantic / validator libs |
Validate at the boundary, not deep inside |
| Caching |
Redis (or managed) |
Use TTLs + invalidation strategy |
| Background Jobs |
BullMQ / platform queues |
Make jobs idempotent + retry-safe |
| Testing |
Unit + integration + contract/E2E |
Keep most tests below the UI layer |
| Observability |
Structured logs + OpenTelemetry |
Correlation IDs end-to-end |
Scope
Use this skill to:
- Design and implement REST/GraphQL/tRPC APIs
- Model data schemas and run safe migrations
- Implement authentication/authorization (OIDC/OAuth, sessions/JWT)
- Add validation, error handling, rate limiting, caching, and background jobs
- Ship production readiness (timeouts, observability, deploy/runbooks)
When NOT to Use This Skill
Use a different skill when:
Decision Tree: Backend Technology Selection
Backend project needs: [API Type]
- REST API?
- Simple CRUD -> Express/Fastify + Prisma/Drizzle
- Enterprise features -> NestJS (DI, modules)
- High performance -> Fastify (tight request lifecycle)
- Edge/Serverless -> Hono (Cloudflare Workers, Vercel Edge)
- Type-Safe API?
- Full-stack TypeScript monorepo -> tRPC (no schema, no codegen)
- Public API with docs -> REST + OpenAPI
- Flexible data fetching -> GraphQL + Pothos/Apollo
- GraphQL API?
- Code-first -> Pothos GraphQL (TypeScript)
- Schema-first -> Apollo Server + GraphQL Codegen
- Runtime Selection?
- Enterprise stable -> Node.js (current LTS)
- Performance-critical -> Bun (verify runtime constraints)
- Security-focused -> Deno (verify platform support)
- Authentication Strategy?
- Browser sessions -> httpOnly cookies + server-side session store
- OAuth/Social -> OIDC/OAuth library (or platform auth)
- Service-to-service -> short-lived JWT + mTLS where possible
- Database Layer?
- Type-safe ORM -> Prisma (migrations, Studio)
- SQL-first/perf -> Drizzle (SQL-like API)
- Raw SQL -> driver + query builder (Kysely/sqlc/SQLx)
- Edge-compatible -> driver/ORM + Neon/Turso/D1
- Caching Strategy?
- Distributed cache -> Redis (multi-server)
- Serverless cache -> managed Redis (e.g., Upstash)
- In-memory cache -> process memory (single instance only)
- Edge Deployment?
- Global low-latency -> Cloudflare Workers
- Next.js integration -> Vercel Edge Functions
- AWS ecosystem -> Lambda@Edge
- Background Jobs?
- Complex workflows -> BullMQ (Redis-backed, retries)
- Serverless workflows -> AWS Step Functions
- Simple scheduling -> cron + durable storage
Runtime & Language Alternatives:
- Node.js (current LTS) (Express/Fastify/NestJS + Prisma/Drizzle): default for broad ecosystem + mature tooling
- Bun (Hono/Elysia + Drizzle): consider for perf-sensitive workloads (verify runtime constraints)
- Python (FastAPI + SQLAlchemy): strong for data-heavy services and ML integration
- Go (Fiber/Gin + GORM/sqlc): strong for concurrency and simple deploys
- Rust (Axum + SeaORM/SQLx): strong for safety/performance-critical services
See assets/ for language-specific starter templates and references/edge-deployment-guide.md for edge computing patterns.
API Design Patterns (Dec 2025)
Idempotency Patterns
All mutating operations MUST support idempotency for retry safety.
Implementation:
// Idempotency key header
const idempotencyKey = request.headers['idempotency-key'];
const cached = await redis.get(`idem:${idempotencyKey}`);
if (cached) return JSON.parse(cached);
const result = await processOperation();
await redis.set(`idem:${idempotencyKey}`, JSON.stringify(result), 'EX', 86400);
return result;
| Do |
Avoid |
| Store idempotency keys with TTL (24h typical) |
Processing duplicate requests |
| Return cached response for duplicate keys |
Different responses for same key |
| Use client-generated UUIDs |
Server-generated keys |
Pagination Patterns
| Pattern |
Use When |
Example |
| Cursor-based |
Large datasets, real-time data |
?cursor=abc123&limit=20 |
| Offset-based |
Small datasets, random access |
?page=3&per_page=20 |
| Keyset |
Sorted data, high performance |
?after_id=1000&limit=20 |
Prefer cursor-based pagination for APIs with frequent inserts.
Error Response Standard (Problem Details)
Use a consistent machine-readable error format (RFC 9457 Problem Details): https://www.rfc-editor.org/rfc/rfc9457
{
"type": "https://example.com/problems/invalid-request",
"title": "Invalid request",
"status": 400,
"detail": "email is required",
"instance": "/v1/users"
}
Health Check Patterns
// Liveness: Is the process running?
app.get('/health/live', (req, res) => {
res.status(200).json({ status: 'ok' });
});
// Readiness: Can the service handle traffic?
app.get('/health/ready', async (req, res) => {
const dbOk = await checkDatabase();
const cacheOk = await checkRedis();
if (dbOk && cacheOk) {
res.status(200).json({ status: 'ready', db: 'ok', cache: 'ok' });
} else {
res.status(503).json({ status: 'not ready', db: dbOk, cache: cacheOk });
}
});
Migration Rollback Strategies
| Strategy |
Description |
Use When |
| Backward-compatible |
New code works with old schema |
Zero-downtime deployments |
| Expand-contract |
Add new, migrate, remove old |
Schema changes |
| Shadow tables |
Write to both during transition |
High-risk migrations |
Common Backend Mistakes to Avoid
| FAIL Avoid |
PASS Instead |
Why |
| Storing sessions in memory |
Use Redis/Upstash |
Memory lost on restart, no horizontal scaling |
| Synchronous file I/O |
Use fs.promises or streams |
Blocks event loop, kills throughput |
| Unbounded queries |
Always use LIMIT + cursor pagination |
Memory exhaustion, slow responses |
| Trusting client input |
Validate with Zod at API boundaries |
Injection attacks, type coercion bugs |
| Hardcoded secrets |
Use env vars + secret manager (Vault, AWS SM) |
Security breach on repo exposure |
| N+1 database queries |
Use include/select or DataLoader |
10-100x performance degradation |
console.log in production |
Use structured logging (Pino/Winston) |
No correlation IDs, unqueryable logs |
| Catching errors silently |
Log + rethrow or handle explicitly |
Hidden failures, debugging nightmares |
| Missing connection pooling |
Use Prisma connection pool or PgBouncer |
Connection exhaustion under load |
| No request timeouts |
Set timeouts on HTTP clients and DB queries |
Resource leaks, cascading failures |
Security anti-patterns:
- FAIL Don't use MD5/SHA1 for passwords -> Use Argon2id
- FAIL Don't store JWTs in localStorage -> Use httpOnly cookies
- FAIL Don't trust
X-Forwarded-For without validation -> Configure trusted proxies
- FAIL Don't skip rate limiting -> Use sliding window (Redis) or token bucket
- FAIL Don't log sensitive data -> Redact PII, tokens, passwords
Optional: AI/Automation Extensions
Note: AI-assisted backend patterns. Skip if not using AI tooling.
AI-Assisted Code Generation
| Tool |
Use Case |
| GitHub Copilot |
Inline suggestions, boilerplate |
| Cursor |
AI-first IDE, context-aware |
| Claude Code |
CLI-based development |
Review requirements for AI-generated code:
- All imports verified against package.json
- Type checker passes (strict mode)
- Security scan passes
- Tests cover generated code
Infrastructure Economics and Business Impact
Why this matters: Backend decisions directly impact revenue. A 100ms latency increase can reduce conversions by 7%. A poorly chosen architecture can cost 10x more in cloud spend. Performance SLAs are revenue commitments.
Cost Modeling Quick Reference
| Decision |
Cost Impact |
Revenue Impact |
| Edge vs. Origin |
60-80% latency reduction |
+2-5% conversion rate |
| Serverless vs. Containers |
Variable cost, scales to zero |
Better unit economics at low scale |
| Reserved vs. On-Demand |
30-60% cost savings |
Predictable COGS |
| Connection pooling |
50-70% fewer DB connections |
Lower database costs |
| Caching layer |
80-95% fewer origin requests |
Reduced compute costs |
Performance SLA -> Revenue Mapping
SLA Target -> Business Metric
P50 latency < 100ms -> Baseline user experience
P95 latency < 500ms -> 95% users satisfied
P99 latency < 1000ms -> Enterprise SLA compliance
Uptime 99.9% (43.8m downtime/month) -> Standard SLA tier
Uptime 99.99% (4.4m downtime/month) -> Enterprise tier ($$$)
Unit Economics Checklist
Before deploying any backend service, calculate:
Architecture Decision -> Business Impact
| Architecture Choice |
Technical Benefit |
Business Impact |
| CDN + Edge caching |
Lower latency |
Higher conversion, better SEO |
| Read replicas |
Scale reads |
Handle traffic spikes without degradation |
| Queue-based processing |
Decouple services |
Smoother UX during high load |
| Multi-region deployment |
Fault tolerance |
Enterprise SLA compliance |
| Auto-scaling |
Right-sized infra |
Lower COGS, better margins |
FinOps Practices for Backend Teams
- Tag all resources - Every resource tagged with
team, service, environment
- Set billing alerts - Alert at 50%, 80%, 100% of budget
- Review weekly - 15-minute weekly cost review meeting
- Right-size monthly - Check CPU/memory utilization, downsize overprovisioned
- Spot/Preemptible for non-prod - 60-90% savings on dev/staging
See references/infrastructure-economics.md for detailed cost modeling, cloud provider comparisons, and ROI calculators.
Navigation
Resources
- references/backend-best-practices.md - Template authoring guide, quality checklist, and shared utilities pointers
- references/edge-deployment-guide.md - Edge computing patterns, Cloudflare Workers vs Vercel Edge, tRPC, Hono, Bun
- references/infrastructure-economics.md - Cost modeling, performance SLAs -> revenue, FinOps practices, cloud optimization
- references/go-best-practices.md - Go idioms, concurrency, error handling, GORM usage, testing, profiling
- references/rust-best-practices.md - Ownership, async, Axum, SeaORM, error handling, testing
- references/python-best-practices.md - FastAPI, SQLAlchemy, async patterns, validation, testing, performance
- data/sources.json - External references per language/runtime
- Shared checklists: ../software-clean-code-standard/assets/checklists/backend-api-review-checklist.md, ../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md
Shared Utilities (Centralized patterns - extract, don't duplicate)
- ../software-clean-code-standard/utilities/auth-utilities.md - Argon2id, jose JWT, OAuth 2.1/PKCE
- ../software-clean-code-standard/utilities/error-handling.md - Effect Result types, correlation IDs
- ../software-clean-code-standard/utilities/config-validation.md - Zod 3.24+, Valibot, secrets management
- ../software-clean-code-standard/utilities/resilience-utilities.md - p-retry v6, opossum v8, OTel spans
- ../software-clean-code-standard/utilities/logging-utilities.md - pino v9 + OpenTelemetry integration
- ../software-clean-code-standard/utilities/testing-utilities.md - Vitest, MSW v2, factories, fixtures
- ../software-clean-code-standard/utilities/observability-utilities.md - OpenTelemetry SDK, tracing, metrics
- ../software-clean-code-standard/references/clean-code-standard.md - Canonical clean code rules (
CC-*) for citation
Templates
- assets/nodejs/template-nodejs-prisma-postgres.md - Node.js + Prisma + PostgreSQL
- assets/go/template-go-fiber-gorm.md - Go + Fiber + GORM + PostgreSQL
- assets/rust/template-rust-axum-seaorm.md - Rust + Axum + SeaORM + PostgreSQL
- assets/python/template-python-fastapi-sqlalchemy.md - Python + FastAPI + SQLAlchemy + PostgreSQL
Related Skills
- ../software-architecture-design/SKILL.md - System decomposition, SLAs, and data flows
- ../software-security-appsec/SKILL.md - Authentication/authorization and secure API design
- ../ops-devops-platform/SKILL.md - CI/CD, infrastructure, and deployment safety
- ../qa-resilience/SKILL.md - Resilience, retries, and failure playbooks
- ../software-code-review/SKILL.md - Review checklists and standards for backend changes
- ../qa-testing-strategy/SKILL.md - Testing strategies, test pyramids, and coverage goals
- ../dev-api-design/SKILL.md - RESTful design, GraphQL, and API versioning patterns
- ../data-sql-optimization/SKILL.md - SQL optimization, indexing, and query tuning patterns
Freshness Protocol
When users ask version-sensitive recommendation questions, do a quick freshness check before asserting "best" choices or quoting versions.
Trigger Conditions
- "What's the best backend framework for [use case]?"
- "What should I use for [API design/auth/database]?"
- "What's the latest in Node.js/Go/Rust?"
- "Current best practices for [REST/GraphQL/tRPC]?"
- "Is [framework/runtime] still relevant in 2026?"
- "[Express] vs [Fastify] vs [Hono]?"
- "Best ORM for [database/use case]?"
How to Freshness-Check
- Start from
data/sources.json (official docs, release notes, support policies).
- Run a targeted web search for the specific component and open release notes/support policy pages.
- Prefer official sources over blogs for versions and support windows.
What to Report
- Current landscape: what is stable and widely used now
- Emerging trends: what is gaining traction (and why)
- Deprecated/declining: what is falling out of favor (and why)
- Recommendation: default choice + 1-2 alternatives, with trade-offs
Example Topics (verify with fresh search)
- Node.js LTS support window and major changes
- Bun vs Deno vs Node.js
- Hono, Elysia, and edge-first frameworks
- Drizzle vs Prisma for TypeScript
- tRPC and end-to-end type safety
- Edge computing and serverless patterns
Operational Playbooks
- references/operational-playbook.md - Full backend architecture patterns, checklists, TypeScript notes, and decision tables
1---2name: software-backend3description: Production-grade backend service development across Node.js (Express/Fastify/NestJS/Hono), Bun, Python (FastAPI), Go, and Rust (Axum), with PostgreSQL and common ORMs (Prisma/Drizzle/SQLAlchemy/GORM/SeaORM). Use for REST/GraphQL/tRPC APIs, auth (OIDC/OAuth), caching, background jobs, observability (OpenTelemetry), testing, deployment readiness, and zero-trust defaults.4---5
6# Software Backend Engineering
7
8Use this skill to design, implement, and review production-grade backend services: API boundaries, data layer, auth, caching, observability, error handling, testing, and deployment.
9
10Defaults to bias toward: type-safe boundaries (validation at the edge), OpenTelemetry for observability, zero-trust assumptions, idempotency for retries, RFC 9457 errors, Postgres + pooling, structured logs, timeouts, and rate limiting.
11
12---
13
14## Quick Reference
15
16| Task | Default Picks | Notes |
17|------|---------------|-------|
18| REST API | Fastify / Express / NestJS | Prefer typed boundaries + explicit timeouts |
19| Edge API | Hono / platform-native handlers | Keep work stateless, CPU-light |
20| Type-Safe API | tRPC | Prefer for TS monorepos and internal APIs |
21| GraphQL API | Apollo Server / Pothos | Prefer for complex client-driven queries |
22| Database | PostgreSQL | Use pooling + migrations + query budgets |
23| ORM / Query Layer | Prisma / Drizzle / SQLAlchemy / GORM / SeaORM | Prefer explicit transactions |
24| Authentication | OIDC/OAuth + sessions/JWT | Prefer httpOnly cookies for browsers |
25| Validation | Zod / Pydantic / validator libs | Validate at the boundary, not deep inside |
26| Caching | Redis (or managed) | Use TTLs + invalidation strategy |
27| Background Jobs | BullMQ / platform queues | Make jobs idempotent + retry-safe |
28| Testing | Unit + integration + contract/E2E | Keep most tests below the UI layer |
29| Observability | Structured logs + OpenTelemetry | Correlation IDs end-to-end |
30
31## Scope
32
33Use this skill to:
34
35- Design and implement REST/GraphQL/tRPC APIs
36- Model data schemas and run safe migrations
37- Implement authentication/authorization (OIDC/OAuth, sessions/JWT)
38- Add validation, error handling, rate limiting, caching, and background jobs
39- Ship production readiness (timeouts, observability, deploy/runbooks)
40
41## When NOT to Use This Skill
42
43Use a different skill when:
44
45- **Frontend-only concerns** -> See [software-frontend](../software-frontend/SKILL.md)
46- **Infrastructure provisioning (Terraform, K8s manifests)** -> See [ops-devops-platform](../ops-devops-platform/SKILL.md)
47- **API design patterns only (no implementation)** -> See [dev-api-design](../dev-api-design/SKILL.md)
48- **SQL query optimization and indexing** -> See [data-sql-optimization](../data-sql-optimization/SKILL.md)
49- **Security audits and threat modeling** -> See [software-security-appsec](../software-security-appsec/SKILL.md)
50- **System architecture (beyond single service)** -> See [software-architecture-design](../software-architecture-design/SKILL.md)
51
52## Decision Tree: Backend Technology Selection
53
54```text
55Backend project needs: [API Type]
56 - REST API?
57 - Simple CRUD -> Express/Fastify + Prisma/Drizzle
58 - Enterprise features -> NestJS (DI, modules)
59 - High performance -> Fastify (tight request lifecycle)
60 - Edge/Serverless -> Hono (Cloudflare Workers, Vercel Edge)
61
62 - Type-Safe API?
63 - Full-stack TypeScript monorepo -> tRPC (no schema, no codegen)
64 - Public API with docs -> REST + OpenAPI
65 - Flexible data fetching -> GraphQL + Pothos/Apollo
66
67 - GraphQL API?
68 - Code-first -> Pothos GraphQL (TypeScript)
69 - Schema-first -> Apollo Server + GraphQL Codegen
70
71 - Runtime Selection?
72 - Enterprise stable -> Node.js (current LTS)
73 - Performance-critical -> Bun (verify runtime constraints)
74 - Security-focused -> Deno (verify platform support)
75
76 - Authentication Strategy?
77 - Browser sessions -> httpOnly cookies + server-side session store
78 - OAuth/Social -> OIDC/OAuth library (or platform auth)
79 - Service-to-service -> short-lived JWT + mTLS where possible
80
81 - Database Layer?
82 - Type-safe ORM -> Prisma (migrations, Studio)
83 - SQL-first/perf -> Drizzle (SQL-like API)
84 - Raw SQL -> driver + query builder (Kysely/sqlc/SQLx)
85 - Edge-compatible -> driver/ORM + Neon/Turso/D1
86
87 - Caching Strategy?
88 - Distributed cache -> Redis (multi-server)
89 - Serverless cache -> managed Redis (e.g., Upstash)
90 - In-memory cache -> process memory (single instance only)
91
92 - Edge Deployment?
93 - Global low-latency -> Cloudflare Workers
94 - Next.js integration -> Vercel Edge Functions
95 - AWS ecosystem -> Lambda@Edge
96
97 - Background Jobs?
98 - Complex workflows -> BullMQ (Redis-backed, retries)
99 - Serverless workflows -> AWS Step Functions
100 - Simple scheduling -> cron + durable storage
101```
102
103**Runtime & Language Alternatives:**
104
105- **Node.js (current LTS)** (Express/Fastify/NestJS + Prisma/Drizzle): default for broad ecosystem + mature tooling
106- **Bun** (Hono/Elysia + Drizzle): consider for perf-sensitive workloads (verify runtime constraints)
107- **Python** (FastAPI + SQLAlchemy): strong for data-heavy services and ML integration
108- **Go** (Fiber/Gin + GORM/sqlc): strong for concurrency and simple deploys
109- **Rust** (Axum + SeaORM/SQLx): strong for safety/performance-critical services
110
111See [assets/](assets/) for language-specific starter templates and [references/edge-deployment-guide.md](references/edge-deployment-guide.md) for edge computing patterns.
112
113---
114
115## API Design Patterns (Dec 2025)
116
117### Idempotency Patterns
118
119All mutating operations MUST support idempotency for retry safety.
120
121**Implementation:**
122
123```typescript
124// Idempotency key header
125const idempotencyKey = request.headers['idempotency-key'];
126const cached = await redis.get(`idem:${idempotencyKey}`);
127if (cached) return JSON.parse(cached);
128
129const result = await processOperation();
130await redis.set(`idem:${idempotencyKey}`, JSON.stringify(result), 'EX', 86400);
131return result;
132```
133
134| Do | Avoid |
135|----|-------|
136| Store idempotency keys with TTL (24h typical) | Processing duplicate requests |
137| Return cached response for duplicate keys | Different responses for same key |
138| Use client-generated UUIDs | Server-generated keys |
139
140### Pagination Patterns
141
142| Pattern | Use When | Example |
143|---------|----------|---------|
144| Cursor-based | Large datasets, real-time data | `?cursor=abc123&limit=20` |
145| Offset-based | Small datasets, random access | `?page=3&per_page=20` |
146| Keyset | Sorted data, high performance | `?after_id=1000&limit=20` |
147
148**Prefer cursor-based pagination** for APIs with frequent inserts.
149
150### Error Response Standard (Problem Details)
151
152Use a consistent machine-readable error format (RFC 9457 Problem Details): https://www.rfc-editor.org/rfc/rfc9457
153
154```json
155{
156 "type": "https://example.com/problems/invalid-request",
157 "title": "Invalid request",
158 "status": 400,
159 "detail": "email is required",
160 "instance": "/v1/users"
161}
162```
163
164### Health Check Patterns
165
166```typescript
167// Liveness: Is the process running?
168app.get('/health/live', (req, res) => {
169 res.status(200).json({ status: 'ok' });
170});
171
172// Readiness: Can the service handle traffic?
173app.get('/health/ready', async (req, res) => {
174 const dbOk = await checkDatabase();
175 const cacheOk = await checkRedis();
176 if (dbOk && cacheOk) {
177 res.status(200).json({ status: 'ready', db: 'ok', cache: 'ok' });
178 } else {
179 res.status(503).json({ status: 'not ready', db: dbOk, cache: cacheOk });
180 }
181});
182```
183
184### Migration Rollback Strategies
185
186| Strategy | Description | Use When |
187|----------|-------------|----------|
188| Backward-compatible | New code works with old schema | Zero-downtime deployments |
189| Expand-contract | Add new, migrate, remove old | Schema changes |
190| Shadow tables | Write to both during transition | High-risk migrations |
191
192---
193
194### Common Backend Mistakes to Avoid
195
196| FAIL Avoid | PASS Instead | Why |
197|----------|-----------|-----|
198| Storing sessions in memory | Use Redis/Upstash | Memory lost on restart, no horizontal scaling |
199| Synchronous file I/O | Use `fs.promises` or streams | Blocks event loop, kills throughput |
200| Unbounded queries | Always use `LIMIT` + cursor pagination | Memory exhaustion, slow responses |
201| Trusting client input | Validate with Zod at API boundaries | Injection attacks, type coercion bugs |
202| Hardcoded secrets | Use env vars + secret manager (Vault, AWS SM) | Security breach on repo exposure |
203| N+1 database queries | Use `include`/`select` or DataLoader | 10-100x performance degradation |
204| `console.log` in production | Use structured logging (Pino/Winston) | No correlation IDs, unqueryable logs |
205| Catching errors silently | Log + rethrow or handle explicitly | Hidden failures, debugging nightmares |
206| Missing connection pooling | Use Prisma connection pool or PgBouncer | Connection exhaustion under load |
207| No request timeouts | Set timeouts on HTTP clients and DB queries | Resource leaks, cascading failures |
208
209**Security anti-patterns:**
210
211- FAIL Don't use MD5/SHA1 for passwords -> Use Argon2id
212- FAIL Don't store JWTs in localStorage -> Use httpOnly cookies
213- FAIL Don't trust `X-Forwarded-For` without validation -> Configure trusted proxies
214- FAIL Don't skip rate limiting -> Use sliding window (Redis) or token bucket
215- FAIL Don't log sensitive data -> Redact PII, tokens, passwords
216
217---
218
219### Optional: AI/Automation Extensions
220
221> **Note**: AI-assisted backend patterns. Skip if not using AI tooling.
222
223#### AI-Assisted Code Generation
224
225| Tool | Use Case |
226|------|----------|
227| GitHub Copilot | Inline suggestions, boilerplate |
228| Cursor | AI-first IDE, context-aware |
229| Claude Code | CLI-based development |
230
231**Review requirements for AI-generated code:**
232
233- All imports verified against package.json
234- Type checker passes (strict mode)
235- Security scan passes
236- Tests cover generated code
237
238---
239
240## Infrastructure Economics and Business Impact
241
242**Why this matters**: Backend decisions directly impact revenue. A 100ms latency increase can reduce conversions by 7%. A poorly chosen architecture can cost 10x more in cloud spend. Performance SLAs are revenue commitments.
243
244### Cost Modeling Quick Reference
245
246| Decision | Cost Impact | Revenue Impact |
247|----------|-------------|----------------|
248| Edge vs. Origin | 60-80% latency reduction | +2-5% conversion rate |
249| Serverless vs. Containers | Variable cost, scales to zero | Better unit economics at low scale |
250| Reserved vs. On-Demand | 30-60% cost savings | Predictable COGS |
251| Connection pooling | 50-70% fewer DB connections | Lower database costs |
252| Caching layer | 80-95% fewer origin requests | Reduced compute costs |
253
254### Performance SLA -> Revenue Mapping
255
256```text
257SLA Target -> Business Metric
258
259P50 latency < 100ms -> Baseline user experience
260P95 latency < 500ms -> 95% users satisfied
261P99 latency < 1000ms -> Enterprise SLA compliance
262Uptime 99.9% (43.8m downtime/month) -> Standard SLA tier
263Uptime 99.99% (4.4m downtime/month) -> Enterprise tier ($$$)
264```
265
266### Unit Economics Checklist
267
268Before deploying any backend service, calculate:
269
270- [ ] **Cost per request**: Total infra cost / monthly requests
271- [ ] **Cost per user**: Total infra cost / MAU
272- [ ] **Gross margin impact**: How does infra cost affect product margin?
273- [ ] **Scale economics**: At 10x traffic, does cost scale linearly or worse?
274- [ ] **Break-even point**: At what traffic level does this architecture pay for itself?
275
276### Architecture Decision -> Business Impact
277
278| Architecture Choice | Technical Benefit | Business Impact |
279|---------------------|-------------------|-----------------|
280| CDN + Edge caching | Lower latency | Higher conversion, better SEO |
281| Read replicas | Scale reads | Handle traffic spikes without degradation |
282| Queue-based processing | Decouple services | Smoother UX during high load |
283| Multi-region deployment | Fault tolerance | Enterprise SLA compliance |
284| Auto-scaling | Right-sized infra | Lower COGS, better margins |
285
286### FinOps Practices for Backend Teams
287
2881. **Tag all resources** - Every resource tagged with `team`, `service`, `environment`
2892. **Set billing alerts** - Alert at 50%, 80%, 100% of budget
2903. **Review weekly** - 15-minute weekly cost review meeting
2914. **Right-size monthly** - Check CPU/memory utilization, downsize overprovisioned
2925. **Spot/Preemptible for non-prod** - 60-90% savings on dev/staging
293
294See [references/infrastructure-economics.md](references/infrastructure-economics.md) for detailed cost modeling, cloud provider comparisons, and ROI calculators.
295
296---
297
298## Navigation
299
300**Resources**
301- [references/backend-best-practices.md](references/backend-best-practices.md) - Template authoring guide, quality checklist, and shared utilities pointers
302- [references/edge-deployment-guide.md](references/edge-deployment-guide.md) - Edge computing patterns, Cloudflare Workers vs Vercel Edge, tRPC, Hono, Bun
303- [references/infrastructure-economics.md](references/infrastructure-economics.md) - Cost modeling, performance SLAs -> revenue, FinOps practices, cloud optimization
304- [references/go-best-practices.md](references/go-best-practices.md) - Go idioms, concurrency, error handling, GORM usage, testing, profiling
305- [references/rust-best-practices.md](references/rust-best-practices.md) - Ownership, async, Axum, SeaORM, error handling, testing
306- [references/python-best-practices.md](references/python-best-practices.md) - FastAPI, SQLAlchemy, async patterns, validation, testing, performance
307- [data/sources.json](data/sources.json) - External references per language/runtime
308- Shared checklists: [../software-clean-code-standard/assets/checklists/backend-api-review-checklist.md](../software-clean-code-standard/assets/checklists/backend-api-review-checklist.md), [../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md](../software-clean-code-standard/assets/checklists/secure-code-review-checklist.md)
309
310**Shared Utilities** (Centralized patterns - extract, don't duplicate)
311- [../software-clean-code-standard/utilities/auth-utilities.md](../software-clean-code-standard/utilities/auth-utilities.md) - Argon2id, jose JWT, OAuth 2.1/PKCE
312- [../software-clean-code-standard/utilities/error-handling.md](../software-clean-code-standard/utilities/error-handling.md) - Effect Result types, correlation IDs
313- [../software-clean-code-standard/utilities/config-validation.md](../software-clean-code-standard/utilities/config-validation.md) - Zod 3.24+, Valibot, secrets management
314- [../software-clean-code-standard/utilities/resilience-utilities.md](../software-clean-code-standard/utilities/resilience-utilities.md) - p-retry v6, opossum v8, OTel spans
315- [../software-clean-code-standard/utilities/logging-utilities.md](../software-clean-code-standard/utilities/logging-utilities.md) - pino v9 + OpenTelemetry integration
316- [../software-clean-code-standard/utilities/testing-utilities.md](../software-clean-code-standard/utilities/testing-utilities.md) - Vitest, MSW v2, factories, fixtures
317- [../software-clean-code-standard/utilities/observability-utilities.md](../software-clean-code-standard/utilities/observability-utilities.md) - OpenTelemetry SDK, tracing, metrics
318- [../software-clean-code-standard/references/clean-code-standard.md](../software-clean-code-standard/references/clean-code-standard.md) - Canonical clean code rules (`CC-*`) for citation
319
320**Templates**
321- [assets/nodejs/template-nodejs-prisma-postgres.md](assets/nodejs/template-nodejs-prisma-postgres.md) - Node.js + Prisma + PostgreSQL
322- [assets/go/template-go-fiber-gorm.md](assets/go/template-go-fiber-gorm.md) - Go + Fiber + GORM + PostgreSQL
323- [assets/rust/template-rust-axum-seaorm.md](assets/rust/template-rust-axum-seaorm.md) - Rust + Axum + SeaORM + PostgreSQL
324- [assets/python/template-python-fastapi-sqlalchemy.md](assets/python/template-python-fastapi-sqlalchemy.md) - Python + FastAPI + SQLAlchemy + PostgreSQL
325
326**Related Skills**
327- [../software-architecture-design/SKILL.md](../software-architecture-design/SKILL.md) - System decomposition, SLAs, and data flows
328- [../software-security-appsec/SKILL.md](../software-security-appsec/SKILL.md) - Authentication/authorization and secure API design
329- [../ops-devops-platform/SKILL.md](../ops-devops-platform/SKILL.md) - CI/CD, infrastructure, and deployment safety
330- [../qa-resilience/SKILL.md](../qa-resilience/SKILL.md) - Resilience, retries, and failure playbooks
331- [../software-code-review/SKILL.md](../software-code-review/SKILL.md) - Review checklists and standards for backend changes
332- [../qa-testing-strategy/SKILL.md](../qa-testing-strategy/SKILL.md) - Testing strategies, test pyramids, and coverage goals
333- [../dev-api-design/SKILL.md](../dev-api-design/SKILL.md) - RESTful design, GraphQL, and API versioning patterns
334- [../data-sql-optimization/SKILL.md](../data-sql-optimization/SKILL.md) - SQL optimization, indexing, and query tuning patterns
335
336---
337
338## Freshness Protocol
339
340When users ask version-sensitive recommendation questions, do a quick freshness check before asserting "best" choices or quoting versions.
341
342### Trigger Conditions
343
344- "What's the best backend framework for [use case]?"
345- "What should I use for [API design/auth/database]?"
346- "What's the latest in Node.js/Go/Rust?"
347- "Current best practices for [REST/GraphQL/tRPC]?"
348- "Is [framework/runtime] still relevant in 2026?"
349- "[Express] vs [Fastify] vs [Hono]?"
350- "Best ORM for [database/use case]?"
351
352### How to Freshness-Check
353
3541. Start from `data/sources.json` (official docs, release notes, support policies).
3552. Run a targeted web search for the specific component and open release notes/support policy pages.
3563. Prefer official sources over blogs for versions and support windows.
357
358### What to Report
359
360- **Current landscape**: what is stable and widely used now
361- **Emerging trends**: what is gaining traction (and why)
362- **Deprecated/declining**: what is falling out of favor (and why)
363- **Recommendation**: default choice + 1-2 alternatives, with trade-offs
364
365### Example Topics (verify with fresh search)
366
367- Node.js LTS support window and major changes
368- Bun vs Deno vs Node.js
369- Hono, Elysia, and edge-first frameworks
370- Drizzle vs Prisma for TypeScript
371- tRPC and end-to-end type safety
372- Edge computing and serverless patterns
373
374---
375
376## Operational Playbooks
377- [references/operational-playbook.md](references/operational-playbook.md) - Full backend architecture patterns, checklists, TypeScript notes, and decision tables