Backend Patterns: Reliable Data and Service Boundaries

What it does

The backend source surveys API handlers, service and repository patterns, middleware, query optimization, caching and background jobs. Its recurring concern is where responsibility belongs when a request crosses storage or an external service. Examples show transactions for related writes, batching to avoid N+1 queries and structured errors that preserve diagnostic value. These patterns are options for a concrete failure mode. A small handler does not need a repository interface merely because an example contains one, and a cache should solve measured load rather than compensate for an unexamined query.

When to use it

• Stop partial order updates when one of several related database writes fails.
• Reduce a dashboard that issues a separate query for every returned item.
• Review retry behavior around an unreliable external inventory service.

Step-by-step workflow

1. Trace one request through validation, authorization, storage and external calls; mark side effects and existing failure handling.
2. Measure query counts and identify missing transaction boundaries before considering new layers or caches.
3. Select the minimum change, such as a batched query or database transaction, that addresses the observed failure.
4. Define retry eligibility, limits and idempotency around external effects; record what operators can safely repeat.
5. Verify success, rollback and dependency-failure paths, then document logs and recovery steps without recording secrets.

Example request

Inspect our order-confirmation handler. It writes the order and stock reservation, then calls an email provider. Show where a database transaction is necessary and where it cannot cover the remote call. Keep the current framework and dependency set. Prevent duplicate confirmation on a retried request, distinguish retryable timeouts from validation errors and identify the query-count baseline. Propose only boundaries justified by the code. Deliver one focused patch, failure-path checks and an operator note explaining how to investigate a pending notification.

Worked example

Suppose stock reservation succeeds but order insertion fails. Wrapping those database operations in one supported transaction prevents a reservation from surviving alone. An email request still cannot be rolled back by that transaction. A durable pending-notification record may be justified if delivery must survive a crash, with an idempotency key at the send boundary where available. Before introducing a queue service, inspect whether the existing database and worker already provide that mechanism. The check should interrupt the workflow after commit and confirm that recovery sends once rather than recreating the order.

What you get

An annotated request flow, a small implementation change, observed query counts and evidence for rollback and recovery behavior.

How to evaluate the result

• A failed related write leaves no partial committed business state.
• Retries do not repeat a consequential remote effect.
• Logs identify the failing operation without credentials or personal payloads.

What you need

Repository access, a safe database fixture and knowledge of the external provider’s retry and idempotency contract. Use an isolated test account for side effects.

Setup and activation

The reviewed ECC source provides an .agents skill layout. Consult the repository README for the chosen client, retain referenced supporting files and explicitly activate only the workflow needed. This catalogue read source files; it installed and executed nothing. Client compatibility depends on available tools and instruction loading, and was not runtime-tested here. Before installation, scan the exact source version, review permissions and use disposable non-sensitive examples.

Limits and considerations

A transaction cannot atomically include an arbitrary HTTP service. In-memory rate limits and queues do not provide shared enforcement or durability across processes. Cache invalidation, authorization and retries need explicit rules; copying a code sample does not establish those rules.

Related workflows

• Use API Design for public request semantics.
• Use Verification Loop to separate local tests from actual deployment acceptance.

License and reuse

MIT in the selected SKILL.md and repository LICENSE. Preserve notices; external packages, services and example dependencies retain their own terms.

Further reading

• Reviewed skill at immutable commit
• Reviewed publisher README
• Reviewed MIT license