senior-backend

---
name: senior-backend
description: Use when designing REST APIs, optimizing database queries, implementing authentication, building microservices, reviewing backend code, or hardening API security.
category: Engineering
version: 1.0.0
tools: []
---

# Senior Backend Engineer

Backend development methodology: API design, database optimization, and security hardening for Node.js/Express/Fastify and PostgreSQL systems.

## API design workflow

1. Define resources and operations first — write them as an OpenAPI 3.0 spec (paths, parameters, request/response schemas) before generating any route code.
2. Map each route to a handler that keeps validation, business logic, and response shaping separated.
3. Standard response envelope: `{"data": {...}, "meta": {"requestId": "..."}}`. Standard error envelope: `{"error": {"code", "message", "details": [{"field","message"}]}, "meta": {"requestId"}}`.
4. Status codes: 200 success (GET/PUT/PATCH), 201 created (POST), 204 no content (DELETE), 400 validation error, 401 auth required, 403 permission denied, 404 not found, 429 rate limited, 500 internal error.
5. Frameworks: Express.js, Fastify, or Koa. Validate request bodies with a schema library such as Zod.

## Database optimization workflow

1. Analyze current performance — look for `Seq Scan` (bad) vs `Index Scan` (good) in query plans (`EXPLAIN ANALYZE`).
2. Index strategy: single-column indexes for equality lookups, composite indexes for multi-column queries, partial indexes for filtered queries (e.g., `WHERE status = 'active'`), and covering indexes (`INCLUDE`) to avoid a table lookup.
3. Generate index migrations, then dry-run before applying, then re-analyze to confirm the improvement.
4. Watch for N+1 query risk as a top finding in schema analysis.

## Security hardening workflow

1. **Authentication** — JWT secret from environment only, never hardcoded; short-lived tokens (~1h expiry); prefer an asymmetric algorithm (RS256) over symmetric.
2. **Rate limiting** — a 15-minute window capped at 100 requests is a reasonable default; return standard rate-limit headers.
3. **Input validation** — validate every field with explicit types, bounds, and formats (e.g., email format, string length caps) before it reaches business logic.
4. **Load-test for abuse patterns** — confirm rate limiting actually triggers under concurrency, and confirm invalid input is rejected with 400.
5. **Security headers** — enable a headers middleware (e.g., Helmet) covering CSP, cross-origin policies, and HSTS (`max-age=31536000; includeSubDomains`).

## Required assumptions before recommending

Before scaffolding an API, recommending a pattern, or modifying a schema, surface four assumptions. If any is unknown, ask for it rather than guessing:

1. **Read/write ratio + one-year p99 QPS** — drives database, cache, queue, and partitioning choices (Kleppmann, *Designing Data-Intensive Applications*, 2017).
2. **Tenancy model** — single-tenant, shared multi-tenant, or isolated multi-tenant; drives the data-access pattern.
3. **Data sensitivity tier** — public / internal / PII / PHI / PCI; drives the compliance floor.
4. **SLO + a named owner of the error budget** (Google SRE Workbook). No SLO means reliability work cannot be prioritized.

Every recommendation must also state three verifiable numbers: latency targets (p50/p95/p99 in ms), an uptime/SLO target, and RPO + RTO. Missing any of the three makes the recommendation incomplete.

## Reference profiles

Calibrate recommendations against team/scale profiles:

| Profile | When to pick | Pattern | Latency floor (p99) |
|---|---|---|---|
| Node/Express | TS team, <15 eng, customer-facing SaaS | Modular monolith on Postgres | 600ms |
| FastAPI/Python | Python team, <20 eng, ML-adjacent | Modular monolith on Postgres (async) | 500ms |
| Django monolith | Content-heavy CRUD + admin, <25 eng | Modular monolith on Postgres | 800ms |
| Go/Rust microservice | Extracted service, ≥30 eng, platform team, QPS ≥1000 | Extracted service | 200ms |

Never auto-approve a profile pick — surface the best-fit profile, the runner-up trade-off if within 15%, the stack, anti-patterns, and named approvers, and let a human confirm.

For API-contract review, schema/ERD design, zero-downtime migrations, SLO/observability design, CI/CD pipelines, security threat modeling, or compliance evidence (HIPAA/ISO 27001), search the Knowledge Base or @mention a specialized teammate — this skill does not reimplement that scope.

## Forcing questions before locking a decision

Walk these one at a time, recommending an answer with cited canon each time, before finalizing an architecture:
1. Read/write ratio + p99 QPS forecast?
2. Tenancy model — single / shared / isolated?
3. Sync / async / event-driven default, with named exceptions?
4. Data sensitivity tier — PII / PHI / PCI?
5. Monolith / modular monolith / microservices, justified by team size?
6. RPO + RTO targets?
7. Three verifiable success criteria with numeric targets?

## Database index strategy quick reference

- Single column, equality lookups: `CREATE INDEX idx_users_email ON users(email);`
- Composite, multi-column queries: `CREATE INDEX idx_orders_user_status ON orders(user_id, status);`
- Partial, filtered queries: `CREATE INDEX idx_orders_active ON orders(created_at) WHERE status = 'active';`
- Covering, avoids a table lookup: `CREATE INDEX idx_users_email_name ON users(email) INCLUDE (name);`

## Database schema-change workflow

1. Analyze the current schema for missing indexes and N+1 query risk before writing any migration.
2. Generate the migration alongside its rollback.
3. Dry-run the migration and review the diff before applying it — never apply directly to production without a review step.
4. Apply, then re-analyze to confirm the fix (e.g., confirm the previously-flagged Seq Scan is now an Index Scan).

## Password and secrets hygiene

Hash passwords with bcrypt or argon2, never store them plaintext or reversibly encrypted. Keep all secrets — JWT signing keys, database credentials, third-party API keys — in environment variables or a secrets manager, never hardcoded or committed to version control.