elite-backend-engineering

name	elite-backend-engineering
description	Design and implement production-grade backend systems with strict contracts, clear boundaries, strong validation, disciplined testing, observability, resilience, and maintainable architecture across languages and frameworks.
risk	safe
source	trysapphire.today
date_added	2026-03-27

Elite Backend Engineering

This skill defines how backend systems must be designed, implemented, validated, and delivered.

It is language-agnostic. It applies to any serious backend stack. It is not tied to a specific framework, runtime, ORM, or cloud provider.

Its purpose is simple:

• produce correct backend systems
• avoid backend slop
• prevent unmaintainable architecture
• force clarity, discipline, and safe delivery

---

1. Use This Skill When

Use this skill for:

• API design
• service implementation
• backend refactors
• backend architecture decisions
• data flow design
• integration design
• background jobs and async workflows
• reliability and observability work
• performance-sensitive backend changes
• backend testing strategy

Do not use this skill for:

• frontend-only work
• small throwaway scripts with no backend lifecycle
• purely cosmetic refactors with no backend implications

---

2. Core Standard

Backend work must be:

• correct
• explicit
• testable
• observable
• secure
• maintainable
• minimal in complexity
• production-oriented

Do not optimize for cleverness. Do not optimize for novelty. Do not optimize for “impressive architecture.”

Optimize for:

• correctness
• operational safety
• simplicity
• long-term maintainability

---

3. First Principle: Understand Before Implementing

Before writing or changing backend code, resolve these questions:

Domain

• What problem does this backend change solve?
• What are the core business rules?
• What must always be true after the operation completes?

Interface

• What are the inputs?
• What are the outputs?
• What errors can occur?
• What are the invalid states?

Operational Reality

• What are the latency, scale, and throughput expectations?
• What consistency model is required?
• What happens on timeout, retry, partial failure, or duplicate request?
• What observability is required?
• What security controls are required?

If these are unclear, do not invent hidden assumptions. Surface them explicitly in the design.

---

4. Architecture Doctrine

4.1 Prefer the Simplest Architecture That Fully Solves the Problem

Start with the simplest correct design.

Do not introduce:

• microservices
• event sourcing
• CQRS
• sagas
• distributed workflows
• heavy caching layers
• advanced async orchestration

unless the requirements clearly justify them.

Simple systems are easier to reason about, test, and operate.

4.2 Clear Boundaries Are Mandatory

Separate backend systems into clear responsibilities.

At minimum, separate:

• transport or delivery layer
• application or orchestration layer
• domain or business logic layer
• persistence and external integration layer
• shared contracts, schemas, and types

Do not mix these concerns inside one file or one function.

4.3 Transport Layers Must Not Contain Business Logic

Handlers, controllers, routes, or endpoints must:

• parse input
• call application logic
• return a response
• map known errors correctly

They must not contain:

• core business rules
• persistence logic
• data access details
• hidden side effects

4.4 Business Logic Must Be Framework-Agnostic

Core business rules must not depend on transport details. They must be testable in isolation.

4.5 Persistence and Integrations Must Be Isolated

Database access, queues, file systems, caches, and external APIs must be behind explicit boundaries. Do not spread direct integration calls across the codebase.

---

5. Modularity Rules

5.1 One Responsibility Per File or Module

Each file or module should have one clear purpose.

If one unit is doing multiple unrelated things, split it.

5.2 No God Files

Large files are usually a design failure.

If a file is growing because it contains:

• transport logic
• business logic
• validation
• persistence
• external API calls
• transformation utilities

it must be broken apart.

5.3 Folder Structure Must Communicate Architecture

The project structure must make responsibilities obvious.

A new engineer should be able to understand:

• where contracts live
• where business logic lives
• where persistence lives
• where integrations live
• where tests live
• where configuration lives

If the structure hides responsibility, the structure is wrong.

---

6. Contracts First

6.1 Define Explicit Contracts

Every backend boundary must have an explicit contract.

That includes:

• request shape
• response shape
• error shape
• event shape
• message shape
• job payload shape
• persistence model boundaries where relevant

6.2 Versioning Must Be Deliberate

If a contract is externally consumed, versioning and compatibility must be considered explicitly.

Do not break consumers casually.

6.3 Errors Must Be Designed, Not Improvised

Define:

• validation errors
• authorization errors
• not found cases
• conflict cases
• rate limit cases
• dependency failures
• internal failures

Do not collapse all failures into vague generic errors.

6.4 Idempotency Must Be Considered

For writes, retries, async workflows, webhooks, payments, or external integrations, explicitly determine whether idempotency is required. If duplicate execution can corrupt state, design for idempotency.

---

7. Typing, Validation, and Data Discipline

7.1 Strong Typing Where the Language Supports It

Use the strongest practical type guarantees available in the stack.

Do not rely on vague dynamic shapes when explicit types or schemas are available.

7.2 Validate All External Input

Every boundary must validate incoming data:

• request bodies
• query parameters
• route parameters
• headers where relevant
• webhook payloads
• queue messages
• scheduled job inputs
• configuration values

No external input is trusted by default.

7.3 Nullability and Optionality Must Be Explicit

Do not hide absence, partial state, or uncertainty. Make optional fields, nullable fields, defaults, and required fields explicit.

7.4 Centralize Configuration

Configuration must come from a single governed source. Do not scatter environment access and configuration parsing throughout the codebase.

---

8. Error Handling and Observability

8.1 No Silent Failure

Never swallow errors. Never log and continue unless the behavior is intentionally safe and documented.

8.2 Errors Must Be Captured With Context

Every operationally relevant failure must include enough context to debug:

• request or operation identity
• actor or caller where appropriate
• affected resource
• failure reason
• retry context if applicable

8.3 Structured Observability Is Mandatory

Backend systems must support:

• structured logging
• metrics
• tracing or equivalent request correlation
• health visibility for critical paths

8.4 Correlation Must Exist Across Boundaries

Requests, jobs, and events must be traceable through the system. Do not create black boxes between services or layers.

---

9. Security Baseline

These are mandatory defaults:

• validate all external input
• enforce authentication where required
• enforce authorization on sensitive actions
• use least privilege for data and service access
• never hardcode secrets
• never trust client-provided authorization claims without verification
• use parameterized or safe query mechanisms
• rate limit externally exposed sensitive surfaces where appropriate
• verify webhook authenticity where applicable
• treat file, network, and deserialization boundaries as hostile by default

Security must be built in, not patched in later.

---

10. Data and Consistency Rules

10.1 Define Invariants

Before implementing writes, define what must remain true in the data model.

10.2 Define Transaction Boundaries

For state changes, determine:

• what must happen atomically
• what may happen asynchronously
• what may fail independently
• what requires compensation or retry

10.3 Consistency Tradeoffs Must Be Explicit

If a workflow is eventually consistent, state that explicitly. Do not let implicit eventual consistency leak into code by accident.

10.4 Concurrency Must Be Considered

For mutable state, consider:

• duplicate requests
• races
• reordering
• retries
• partial completion

If concurrency can break correctness, address it directly.

---

11. Performance and Scalability

11.1 Measure Before Optimizing

Do not guess performance bottlenecks. Identify the actual hot path.

11.2 Optimize the Right Things

Focus on:

• query efficiency
• batch behavior
• pagination
• payload size
• network round trips
• concurrency limits
• timeouts
• connection or resource pool usage
• caching only where justified

11.3 Caching Requires an Invalidation Strategy

Never add cache without answering:

• what is cached
• when it becomes stale
• how it is invalidated
• what happens on cache miss
• whether stale reads are acceptable

11.4 Backpressure and Timeouts Must Exist

Any external dependency or async workload must have:

• timeout behavior
• retry policy where justified
• failure handling
• concurrency limits where needed

---

12. Testing Discipline

Testing is not optional.

12.1 Test Types

Use the right level of testing for the problem:

• unit tests for isolated business logic
• integration tests for real component interaction
• contract tests for interface guarantees
• end-to-end tests only for high-value flows
• load or stress testing only when scale or throughput matters

12.2 Minimum Required Coverage of Risk

Tests must cover:

• happy path
• invalid input
• authorization failures
• not found cases
• conflict cases
• dependency failure cases
• retry or idempotency behavior where relevant
• edge cases around state and concurrency where relevant

12.3 Tests Must Be Isolated

Each test must run independently. No hidden state coupling. No dependence on execution order.

12.4 Do Not Use Production Dependencies in Tests

Tests must not depend on:

• production databases
• real third-party APIs
• shared mutable external state
• real secrets

Mock or isolate external systems deliberately.

12.5 Backend Changes Are Not Done Until Validation Passes

After backend changes, run the strongest validation available for the stack:

• formatter
• linter
• type checker or static analysis
• build or compile checks
• relevant test suites

Do not call the work complete until these pass.

---

13. Comment Policy

Do not over-comment.

Allowed comments:

• non-obvious tradeoffs
• important invariants
• known constraints
• behavior that would otherwise be misunderstood

Do not add comments that restate obvious code.

Clean structure and names are preferred over comment clutter.

---

14. Delivery Rules

14.1 Finish the Full Logical Task

Do not treat a backend task as done when only the happy path is implemented.

Completion requires:

• implementation
• validation
• tests
• error handling
• observability considerations
• security considerations
• cleanup of obvious edge cases

14.2 No Partial Backend Quality

Do not leave behind:

• dead code
• debug artifacts
• hidden TODOs for critical correctness gaps
• inconsistent error handling
• mixed architectural styles

14.3 Safe Change Management

For meaningful backend changes, consider:

• migration impact
• backward compatibility
• rollout risk
• fallback or rollback path
• monitoring after release

---

15. Anti-Patterns

Reject these immediately:

• business logic in handlers or routes
• direct persistence logic spread through the codebase
• direct external API usage everywhere with no abstraction
• giant files with mixed responsibilities
• hidden global state
• unvalidated external input
• silent failure
• vague catch-all error handling
• missing authorization checks
• premature distributed architecture
• caching with no invalidation strategy
• retries with no idempotency thinking
• tests coupled to execution order
• backend work shipped without validation
• architecture designed to look impressive rather than remain operable

---

16. Response Standard

When using this skill, the backend response should be decision-complete.

It should make these things explicit:

• assumptions
• boundaries
• contracts
• validation approach
• error model
• security model
• observability plan
• testing plan
• tradeoffs
• rollout or migration risk when relevant

Do not produce backend code or architecture that leaves core decisions implicit.

---

17. Final Backend Checklist

Before finalizing any backend work, confirm all of the following:

• requirements are explicit
• domain invariants are identified
• boundaries are clear
• contracts are explicit
• external input is validated
• business logic is isolated
• persistence and integrations are isolated
• error handling is deliberate
• observability exists for critical paths
• security controls are present
• consistency and concurrency risks were considered
• performance assumptions were not guessed blindly
• tests cover the meaningful risk
• validation tools pass
• no major anti-patterns remain

---

18. Enforcement Rule

When uncertain:

• choose the simpler design
• make the contract explicit
• isolate the responsibility
• validate the input
• make failure observable
• test the behavior
• remove unnecessary complexity