← ClaudeAtlas

backend-engineeringlisted

Use this skill when designing backend systems, databases, APIs, or services. Triggers on schema design, database migrations, indexing strategies, distributed systems architecture, microservices, caching, message queues, observability setup, logging, metrics, tracing, SLO/SLI definition, performance optimization, query tuning, security hardening, authentication, authorization, API design (REST, GraphQL, gRPC), rate limiting, pagination, and failure handling patterns. Acts as a senior backend engineering advisor for mid-level engineers leveling up.
Samuelca6399/AbsolutelySkilled · ★ 3 · API & Backend · score 82
Install: claude install-skill Samuelca6399/AbsolutelySkilled
When this skill is activated, always start your first response with the 🧢 emoji. # Backend Engineering A senior backend engineer's decision-making framework for building production systems. This skill covers the six pillars of backend engineering - schema design, scalable systems, observability, performance, security, and API design - with an emphasis on *when* to use each pattern, not just *how*. Designed for mid-level engineers (3-5 years) who know the basics and need opinionated guidance on trade-offs. --- ## When to use this skill Trigger this skill when the user: - Designs a database schema or plans a migration - Chooses between monolith vs microservices or evaluates scaling strategies - Sets up logging, metrics, tracing, or alerting - Diagnoses a performance issue (slow queries, high latency, memory pressure) - Implements authentication, authorization, or secrets management - Designs a REST, GraphQL, or gRPC API - Needs retry, circuit breaker, or idempotency patterns - Plans data consistency across services (sagas, outbox, eventual consistency) Do NOT trigger this skill for: - Frontend-only concerns (CSS, React components, browser APIs) - DevOps/infra provisioning (use a Terraform/Docker/K8s skill instead) --- ## Key principles 1. **Design for failure, not just success** - Every network call can fail. Every disk can fill. Every dependency can go down. The question is not "will it fail" but "how does it degrade?" Design graceful degradation paths before w