Backend Patterns

Backend Development Patterns

API Design

RESTful Conventions

GET    /api/users          # List (with pagination)
GET    /api/users/:id      # Read single
POST   /api/users          # Create
PUT    /api/users/:id      # Full update
PATCH  /api/users/:id      # Partial update
DELETE /api/users/:id      # Delete

Response Format

{
  "data": { ... },
  "meta": {
    "page": 1,
    "per_page": 20,
    "total": 142
  }
}

Error Response

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid input",
    "details": [
      { "field": "email", "message": "must be a valid email" }
    ]
  }
}

HTTP Status Codes

Database Patterns

Repository Pattern

Separate data access from business logic:

Service (business logic) → Repository (data access) → Database

Query Optimization

• Add indexes for WHERE, JOIN, and ORDER BY columns
• Use EXPLAIN to verify query plans
• Avoid SELECT * — select only needed columns
• Use pagination for list endpoints (LIMIT/OFFSET or cursor-based)
• Batch operations instead of N+1 queries

Migration Safety

• Always make migrations reversible
• Use CREATE INDEX CONCURRENTLY (PostgreSQL)
• Add columns as nullable first, then backfill, then add constraint
• Never rename columns — add new, migrate data, remove old

Caching Patterns

Cache-Aside (Lazy Loading)

1. Check cache for key
2. If miss: query database, store in cache, return
3. If hit: return cached value
4. On write: invalidate cache

Cache Invalidation

• Time-based: TTL appropriate to data freshness needs
• Event-based: Invalidate on write/update
• Version-based: Include version in cache key

What to Cache

• Database query results (especially aggregations)
• External API responses
• Computed values (rendered templates, transformed data)
• Session data

What NOT to Cache

• Frequently changing data (< 1 second TTL)
• Sensitive data without encryption
• Large blobs that exceed memory budget

Service Architecture

Middleware Pattern

Request → Auth → Rate Limit → Validate → Handler → Response
                                              ↓
                                          Logging

Health Check Endpoint

GET /health
{
  "status": "healthy",
  "checks": {
    "database": "connected",
    "cache": "connected",
    "disk": "sufficient"
  }
}

Rate Limiting

• Per-user rate limits for authenticated endpoints
• Per-IP rate limits for public endpoints
• Return 429 with Retry-After header
• Use sliding window algorithm for accuracy

Graceful Shutdown

1. Stop accepting new connections
2. Finish processing in-flight requests (with timeout)
3. Close database connections
4. Close cache connections
5. Exit