Build robust APIs, databases, and server-side systems

Design a complete REST API for [APPLICATION / FEATURE NAME]. Context: - Application type: [SaaS / mobile app / internal tool / marketplace] - Tech stack: [Node.js/Express / FastAPI / Django / etc.] - Authentication: [JWT / OAuth / API key / session] Resources needed: [LIST YOUR MAIN DATA ENTITIES] For each resource, define: - GET (list + single item) - POST (create) - PUT/PATCH (update) - DELETE Output format for each endpoint: - Method + URL path - Request body (JSON schema) - Response body (JSON schema) - Status codes (success + errors) - Auth required: yes/no Also provide: - Versioning strategy (/api/v1/) - Error response format (consistent structure) - Rate limiting recommendations - 3 non-obvious design decisions to consider

Design a PostgreSQL database schema for [APPLICATION NAME / USE CASE]. Application overview: [DESCRIBE WHAT YOUR APP DOES IN 2-3 SENTENCES] Main entities needed: [LIST THEM] For each table: - Column names, types, constraints - Primary and foreign keys - Indexes (which columns to index and why) - Timestamps (created_at, updated_at) Additional requirements: - [Soft deletes / hard deletes] - [Multi-tenancy / single tenant] - [Row level security needed: yes/no] Output: 1. Complete CREATE TABLE SQL 2. ERD description (which tables relate to which) 3. 3 example queries that will be common in this app 4. Performance considerations for scale

Implement [JWT / session / OAuth] authentication for a [FRAMEWORK] application. Requirements: - Register: email + password - Login: return access token + refresh token - Protected routes middleware - Token refresh endpoint - Logout (invalidate tokens) - Password reset flow Tech stack: [Node.js + Express / FastAPI / etc.] Database: [PostgreSQL / MongoDB / etc.] Security requirements: - Password hashing (bcrypt) - Token expiry: access [15min] / refresh [7 days] - Rate limiting on auth endpoints - Brute force protection Provide: 1. Complete working code for each piece 2. Database tables/models needed 3. Environment variables to configure 4. Security checklist — what I must NOT do

Optimise this slow SQL query and explain what you changed. Query: [PASTE YOUR QUERY] Current execution time: [TIME] Table sizes: [APPROXIMATE ROW COUNTS] Current indexes: [LIST EXISTING INDEXES] Analyse: 1. Query execution plan issues (N+1, full table scans, etc.) 2. Missing indexes 3. Inefficient JOINs or subqueries 4. Data type mismatches 5. Opportunities for query rewriting Provide: - Optimised query - Indexes to add (with CREATE INDEX statements) - Expected performance improvement - EXPLAIN ANALYSE output interpretation - Long-term schema changes to consider

Build a webhook handler for [SERVICE: Stripe / GitHub / Twilio / etc.] in [FRAMEWORK]. Requirements: - Verify webhook signature/secret - Parse event types - Idempotency (handle duplicate events) - Queue processing for slow operations - Error handling and retries - Logging Handle these specific events: [LIST THE WEBHOOK EVENTS YOU NEED] Code should include: 1. Signature verification middleware 2. Event router 3. Individual event handlers 4. Database update logic 5. Retry mechanism 6. Test payload examples

Create a production-ready Docker setup for my [APPLICATION TYPE] application. Stack: - App: [language/framework + version] - Database: [PostgreSQL / MongoDB / etc.] - Cache: [Redis / none] - Reverse proxy: [Nginx / Traefik] Requirements: - Multi-stage build (minimal production image) - Non-root user inside container - Health checks - Environment variable management - Volume mounts for persistent data - Network isolation Provide: 1. Dockerfile (optimised, with explanations) 2. docker-compose.yml for production 3. docker-compose.dev.yml for local development 4. .dockerignore file 5. Deployment commands 6. Common issues and how to debug them

Implement a caching strategy for [API / APPLICATION] using Redis. Current performance issue: [DESCRIBE THE BOTTLENECK] Cache target: [What data to cache and why] Tech stack: [Node.js / Python / etc.] Implement: - Cache-aside pattern for [ENDPOINT / QUERY] - TTL strategy per data type - Cache invalidation on write/update - Cache warming (if applicable) - Cache bypass header for debugging Code should include: 1. Redis client setup 2. Cache middleware/decorator 3. Invalidation logic 4. Monitoring (hit rate logging) 5. Fallback when Redis is down Expected improvement: [CURRENT vs TARGET response time]

Write unit tests for this code using [Jest / Pytest / Vitest / etc.]. Code to test: [PASTE YOUR CODE] Framework: [testing framework] Write tests for: 1. Happy path (expected input → expected output) 2. Edge cases (empty input, max values, special characters) 3. Error cases (invalid input, network failure, null values) 4. Async behaviour (promises, callbacks) 5. Side effects (database calls, API calls — mock these) Structure: - describe() blocks for logical grouping - Meaningful test names ("it should X when Y") - Setup and teardown (beforeEach/afterEach) - Mock strategy for external dependencies Also: suggest what additional tests would increase confidence the most.