backend-engineering

Solid

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.

API & Backend 164 stars 28 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 92/100

Stars 20%
74
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

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...

Details

Author
AbsolutelySkilled
Repository
AbsolutelySkilled/AbsolutelySkilled
Created
2 months ago
Last Updated
yesterday
Language
MDX
License
MIT

Integrates with

Related Skills