magnus919 Backend Engineering Methodology
Backend engineering is the craft of building the server-side systems that power applications — APIs, services, data access, integrations, and the runtime behavior that makes the architecture real. This methodology covers implementation after target design in software-architecture and before quality validation in qa-methodology; use software-architecture-analysis when the current system must first be reverse-engineered. It makes runtime boundaries, transaction behavior, message handling, and coexistence seams executable without taking ownership of the surrounding architecture or migration decision.
The Backend Engineer's Domain
| You own | You don't own |
|---|---|
| API implementation — REST/gRPC/GraphQL endpoints, request validation, response formatting, error handling, middleware chains | API contracts belong to api-design-and-evolution; service decomposition and target boundaries belong to software-architecture |
| Service logic — business rules, workflow orchestration, state management, background job processing | Deployment pipeline and infrastructure — that's platform-engineering |
| Event-driven implementation — domain-event publication, outbox/inbox coordination, handler idempotency, replay and failure paths | Event contract ownership and delivery semantics — that's the api-design-and-evolution |
| Migration seams inside a service — adapters, selectable paths, authority checks, and implementation handoffs | Cross-system migration lifecycle and cutover authority — that's the migration-engineering |
| Database access patterns — query design, connection management, transaction boundaries, N+1 detection, pagination | Data-platform and model strategy belong to data-architect; schema and pipeline operations belong to data-engineering |
| Integration code — third-party API clients, webhook handlers, message queue consumers/producers | Code review and quality gates — that's qa-methodology |
| Observability instrumentation at the service level — structured logging, metrics, tracing hooks | Observability infrastructure and reliability policy belong to platform-engineering and site-reliability-engineering |
| Service-level tests — unit tests for business logic, integration tests for API contracts | Test strategy and automation — that's qa-methodology |
Reference Files
| Reference | When to load |
|---|---|
references/api-patterns.md |
Designing or implementing API endpoints — resource modeling, versioning, pagination, error response formats, request validation |
references/service-patterns.md |
Structuring service logic — clean/hexagonal/layered architecture, dependency injection, middleware composition, request lifecycle, background jobs |
references/event-driven-service-implementation.md |
Implementing event-driven application flows — domain events, unit of work, transactional outbox/inbox, idempotent handlers, retry/replay, observability, and failure handling |
references/migration-coexistence-patterns.md |
Keeping old and new implementations safe to run together — adapters, strangler handoffs, anti-corruption boundaries, dual paths, authority, and removal conditions |
references/database-testing.md |
Database access patterns (connection pooling, query optimization, N+1 detection, pagination strategies, transaction boundaries, read/write splitting, replication lag) and service-level testing (unit testing business logic, integration testing API contracts with test containers/WireMock, contract testing with Pact, test fixtures, CI integration) |
references/integration-patterns.md |
Integrating with external systems — retry with backoff, circuit breakers, idempotency keys, webhook verification, message queue consumers |
references/error-handling.md |
Handling errors systematically — classification (client vs server), structured responses, exception handling patterns, observability correlation |
references/source-index.md |
Provenance and ownership notes for this original synthesis; load when reviewing scope or source boundaries |
Templates
| Template | When to Use |
|---|---|
templates/service-design-record.md |
Designing or restructuring a service — structure, API surface, data access, error handling, and testing plan in one reviewable record |
templates/error-handling-taxonomy.md |
Defining or auditing a service's error contract — classification, response format, retry/idempotency policy, and error-path tests |
Scripts
| Script | When to Use |
|---|---|
scripts/n1-query-spotter.py |
Scanning Python source for potential N+1 query patterns (query-like calls inside loops); --json for CI-friendly output, exit 1 on findings |
Related Skills
- programming-principles — DDD owns bounded contexts, aggregates, domain language, repositories, and domain-modeling guidance. This skill applies those decisions at implementation seams rather than duplicating that catalog.
- api-design-and-evolution — owns event/message contracts, delivery semantics, compatibility, and consumer-facing API decisions.
- migration-engineering — owns cross-system migration classification, compatibility windows, reconciliation, cutover, recovery, deprecation, and cleanup. This skill only implements service-local coexistence seams.
- software-architecture — owns service decomposition and target-boundary strategy; backend engineering implements an approved boundary.
- data-engineering — owns schema migration and pipeline operations; application code may expose the repository or transaction interfaces those operations use.
- secure-software-engineering — owns threat modeling, authorization, secrets, untrusted inputs, and security acceptance evidence.
- release-engineering — owns progressive delivery, artifact promotion, release gates, and rollback mechanics.
- postgres — diagnosing the PostgreSQL side of a database problem: configuration review, index and query-plan issues, vacuum/bloat, backups/PITR, replication and failover. Application-level data access patterns stay here; engine-level operations route there.
- supabase — building on Supabase: migrations, RLS, Auth, Storage, and Edge Functions. To measure an agent's Supabase task competence, use its agent evals harness reference.
Core Principles
The interface is the contract — API boundaries are service-level contracts. Every endpoint signature, request schema, response format, and error code is a promise to consumers. Breaking changes are coordination problems, not version bumps.
Business logic is the center of gravity — Keep business rules isolated from framework concerns, transport protocols, and infrastructure details. A well-structured service can survive changes to its HTTP library, database driver, and deployment platform.
Handle errors where they make sense — Catch errors at the boundary where you have enough context to handle them meaningfully. Catch too early and you lose context. Catch too late and you can't recover.
Design for failure, not just success — Every external call can fail. Every database connection can drop. Every message can be duplicated. Idempotency, retry, and graceful degradation are not optimizations — they're requirements.
Test at the right level — Business logic gets unit tests. API contracts get integration tests. Service boundaries get contract tests. Each level catches a different class of failure.
Implementation Decision Path
- Name the bounded context, aggregate/invariant boundary, and source of truth. Use programming-principles for DDD choices rather than rebuilding its catalog here.
- Put transport, broker, database, clock, and vendor concerns behind ports owned by the application or domain-facing code. Let infrastructure implement those ports.
- For a command that changes durable state and emits a fact, load the aggregate, invoke domain behavior, and commit state plus outbox records in one unit of work. Do not hold that transaction open across network calls.
- For an incoming message, validate the envelope at the edge, deduplicate within the consumer's authority, apply the handler, and acknowledge only after its durable effects commit. Load the event reference for replay and poison-message decisions.
- If old and new paths coexist, record which path is authoritative for each operation, how outputs are compared, and what evidence permits handoff or removal. Load the migration reference for the implementation seam; route the migration lifecycle out.
- Add unit tests for domain/application behavior and boundary integration tests for transaction, outbox, inbox, duplicate, retry, replay, and recovery behavior.
Exit Criteria
This skill is complete when the implementation has explicit dependency direction, transaction and authority boundaries, classified failure/retry behavior, observable message or coexistence paths, focused tests for duplicate and failure cases, and clear links to the neighboring owner for every out-of-scope decision.