| name | backend |
| description | Use when making backend architecture decisions — choosing API styles, database types, caching strategies, authentication mechanisms, and server-side design patterns for scalable, maintainable systems.
USE FOR: backend architecture decisions, choosing API styles, choosing database types, server-side design patterns, backend system design
DO NOT USE FOR: specific pattern details (use sub-skills: data-modeling, api-design, caching, authentication), frontend architecture (use dev/frontend), infrastructure (use iac)
|
| license | MIT |
| metadata | {"displayName":"Backend Architecture","author":"Tyler-R-Kendrick"} |
| compatibility | claude, copilot, cursor |
| references | [{"title":"Martin Fowler — Patterns of Enterprise Application Architecture","url":"https://martinfowler.com/eaaCatalog/"},{"title":"OpenAPI Specification","url":"https://www.openapis.org/"}] |
Backend Architecture
Overview
Backend architecture encompasses the server-side decisions that determine how a system stores data, exposes functionality, handles security, and scales under load. The choices made at this level -- API style, database type, caching strategy, authentication mechanism -- ripple through every layer of the application and are difficult to change once established.
This skill provides a decision-making framework drawn from Martin Kleppmann's Designing Data-Intensive Applications and industry-proven patterns for building reliable, scalable, and maintainable backend systems.
Knowledge Map
┌─────────────────────────────────────────────────────────────────┐
│ API Layer │
│ REST, GraphQL, gRPC, WebSocket │
│ → How clients communicate with the backend │
├─────────────────────────────────────────────────────────────────┤
│ Data Storage │ Caching │
│ Relational, Document, Graph, │ In-memory, Distributed, │
│ Key-Value, Time-Series │ CDN, HTTP caching │
│ → How data is persisted │ → How hot data is served │
├─────────────────────────────────────────────────────────────────┤
│ Authentication & Authorization │ Background Processing │
│ OAuth 2.0, JWT, RBAC, ABAC, │ Job queues, schedulers, │
│ Multi-tenancy │ event-driven workers │
├─────────────────────────────────────────────────────────────────┤
│ Rate Limiting & Throttling │ Observability │
│ Token bucket, sliding window, │ Logging, metrics, tracing, │
│ API quotas, circuit breakers │ health checks, alerting │
└─────────────────────────────────────────────────────────────────┘
Choosing an API Style
| Criterion | REST | GraphQL | gRPC | WebSocket |
|---|
| Best for | CRUD resources, public APIs | Flexible queries, mobile clients | Internal microservices, high throughput | Real-time bidirectional communication |
| Data format | JSON (typically) | JSON | Protobuf (binary) | Any (JSON, binary) |
| Contract | OpenAPI / Swagger | Schema (SDL) | .proto files | No standard schema |
| Caching | HTTP caching (excellent) | Harder (POST-based) | No HTTP caching | Not cacheable |
| Streaming | SSE (server-only) | Subscriptions | Bidirectional streaming | Full-duplex native |
| Browser support | Native | Native | Requires gRPC-Web proxy | Native |
| Learning curve | Low | Medium | Medium-High | Low-Medium |
| Over/under-fetching | Common problem | Solved by design | Defined per RPC | N/A |
| Tooling maturity | Excellent | Good | Good (growing) | Moderate |
Decision heuristic:
- Default to REST for public APIs and simple CRUD services.
- Choose GraphQL when clients need flexible, aggregated queries across multiple resources (especially mobile).
- Choose gRPC for internal service-to-service communication where latency and throughput matter.
- Choose WebSocket when you need real-time, bidirectional data flow (chat, live dashboards, collaborative editing).
- Many systems combine styles: REST for public API, gRPC internally, WebSocket for real-time features.
Choosing a Database Type
| Criterion | Relational (SQL) | Document (NoSQL) | Graph | Key-Value | Time-Series |
|---|
| Best for | Structured data, complex joins, ACID transactions | Flexible schemas, nested data, rapid iteration | Highly connected data, relationship traversal | Simple lookups, caching, session storage | Metrics, IoT, logs, financial ticks |
| Examples | PostgreSQL, MySQL, SQL Server | MongoDB, CouchDB, DynamoDB | Neo4j, Amazon Neptune, ArangoDB | Redis, Memcached, DynamoDB | InfluxDB, TimescaleDB, Prometheus |
| Schema | Strict (schema-on-write) | Flexible (schema-on-read) | Property graph / RDF | Schema-free | Tag + field model |
| Scaling | Vertical (horizontal with sharding) | Horizontal (built-in) | Vertical (some horizontal) | Horizontal (built-in) | Horizontal (built-in) |
| Transactions | Full ACID | Limited (document-level) | Varies by product | None (typically) | None (typically) |
| Query language | SQL | Vendor-specific (MQL, etc.) | Cypher, Gremlin, SPARQL | GET/SET commands | InfluxQL, Flux, SQL |
| Joins | Excellent | Poor (application-level) | Excellent (traversals) | None | Limited |
Decision heuristic:
- Default to relational (PostgreSQL) when data is structured and relationships matter.
- Choose document when schema flexibility and developer velocity are priorities, and joins are rare.
- Choose graph when the primary queries traverse relationships (social networks, recommendations, fraud detection).
- Choose key-value for caching, sessions, and simple lookup-by-key workloads.
- Choose time-series for append-heavy, time-stamped data with downsampling and retention needs.
- Polyglot persistence is common: use the right database for each bounded context.
Backend Architecture Concerns
Rate Limiting & Throttling
Protect backend services from abuse and overload:
- Token Bucket -- allows bursts up to a configured capacity, refills at a steady rate.
- Sliding Window -- counts requests in a rolling time window for smoother limiting.
- Fixed Window -- simple counter per time window (risk of burst at window boundaries).
- Leaky Bucket -- processes requests at a constant rate, queuing excess.
- Implement at the API gateway layer for consistency across services.
Background Processing
Offload long-running or non-urgent work from the request/response cycle:
- Job queues (Sidekiq, Celery, Hangfire, BullMQ) -- enqueue work, process asynchronously.
- Scheduled jobs (cron, Quartz, Hangfire recurring) -- time-triggered processing.
- Event-driven workers -- react to domain events from a message broker.
- Batch processing -- periodic bulk operations (ETL, report generation).
- Always design for idempotency -- workers may process the same job more than once.
Observability
The three pillars of observability, plus health monitoring:
- Logging -- structured logs (JSON) with correlation IDs for request tracing.
- Metrics -- counters, gauges, histograms (request rate, error rate, latency percentiles).
- Distributed Tracing -- end-to-end trace across services (OpenTelemetry, Jaeger, Zipkin).
- Health checks -- liveness (is the process running?) and readiness (can it serve traffic?).
- Alerting -- thresholds on key metrics (error rate > 1%, p99 latency > 500ms).
Canonical Reference
- Designing Data-Intensive Applications by Martin Kleppmann -- the definitive guide to data storage, replication, partitioning, encoding, and distributed system trade-offs. Essential reading for any backend architect.
Sub-Skills
dev/backend/data-modeling -- Data modeling and database architecture patternsdev/backend/api-design -- API design patterns for REST, GraphQL, gRPC, WebSocketdev/backend/caching -- Caching strategies and patternsdev/backend/authentication -- Authentication and authorization patterns
Best Practices
- Start with a monolith and extract services only when complexity demands it -- premature microservices add coordination cost without proportional benefit.
- Choose boring technology by default. PostgreSQL, Redis, and a well-designed REST API solve the vast majority of backend problems.
- Design for failure: every network call can fail, every database can be slow. Use timeouts, retries with backoff, circuit breakers, and fallbacks.
- Make operations idempotent wherever possible -- especially for writes, background jobs, and event handlers.
- Instrument everything from day one. Adding observability retroactively is far more expensive than building it in.
- Treat API contracts as public commitments: version explicitly, deprecate gracefully, never break existing clients without a migration path.
