| name | backend-engineering |
| version | 0.1.0 |
| description | 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.
|
| category | engineering |
| tags | ["backend","databases","api-design","distributed-systems","security","observability"] |
| recommended_skills | ["api-design","database-engineering","observability","system-design"] |
| platforms | ["claude-code","gemini-cli","openai-codex","mcp"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
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
-
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 writing the
happy path.
-
Observe before you optimize - Never guess where the bottleneck is. Instrument
first, measure second, optimize third. A 10ms query called 1000 times matters more
than a 500ms query called once.
-
Simple until proven otherwise - Start with a monolith, a single database, and
synchronous calls. Add complexity (microservices, queues, caches) only when you
have evidence the simple approach fails. Every architectural boundary is a new
failure mode.
-
Secure by default, not by afterthought - Auth, input validation, and encryption
are not features to add later. They are constraints to build within from day one.
Use established libraries. Never roll your own crypto.
-
APIs are contracts, not implementation details - Once published, an API is a
promise. Design from the consumer's perspective inward. Version explicitly. Break
nothing silently.
Core concepts
Backend engineering is the discipline of building reliable, performant, and secure
server-side systems. The six pillars form a hierarchy:
