backend-patterns

Backend Patterns Skill

Degree of freedom: MIXED. Which pattern to apply [HIGH freedom]; existing-architecture probes and the validation list [LOW freedom — run exactly].

How to reason

1. Observe — existing server/api/actions, ORM, queues, cache
2. Interpret — missing pattern vs duplicate vs wrong layer
3. Classify — reuse / add-queue / add-cache / add-rate-limit / edge-fn
4. Severity — unauthenticated mutation outranks a missing cache

Worked example

Observe: createOrder sends email inline; no Inngest/queue; checkout p95 4s. Interpret: confirmation is post-response work, not request-path. Classify: after() or an order/created job; keep the write transactional. Verify: order row commits; email/inventory run after response; retries do not double-charge.

Self-critique before reporting

• Existing first — searched server/api/actions before adding a second pattern
• Auth + validate — every mutation checks session and Zod
• Idempotent — retries on the new path do not double-apply
• Right owner — which architecture to pick → audit-backend-architecture

Design scalable, maintainable backend architectures using modern patterns and best practices.

Code examples lean on Next.js App Router + Supabase/Prisma. The patterns are stack-agnostic — adapt ORMs, client libraries, and deploy targets to your detected ecosystem.

Check existing first [LOW freedom — run exactly]

Before implementing ANY backend pattern, verify:

1. Check existing architecture:

ls -la src/server/ src/api/ app/api/ supabase/functions/ 2>/dev/null
cat package.json | grep -i "prisma\|drizzle\|supabase\|trpc"

1. Check existing patterns:

rg "createTRPCRouter|publicProcedure" --type ts -l
rg "'use server'" --type ts -l
ls -la supabase/migrations/*.sql 2>/dev/null | tail -5

1. Check database setup:

cat prisma/schema.prisma 2>/dev/null | head -50
cat supabase/config.toml 2>/dev/null