Skip to content

docs: refine backend architect operational guidance#536

Open
youngledo wants to merge 1 commit into
msitarzewski:mainfrom
youngledo:docs/backend-architect-operational-guidance
Open

docs: refine backend architect operational guidance#536
youngledo wants to merge 1 commit into
msitarzewski:mainfrom
youngledo:docs/backend-architect-operational-guidance

Conversation

@youngledo
Copy link
Copy Markdown

@youngledo youngledo commented May 18, 2026

Summary

This refines the Backend Architect agent guidance around the responsibilities of designing production-ready backend systems.

The update adds guidance for:

  • choosing monolith, modular monolith, microservices, or serverless based on team size, domain/service boundaries, operational maturity, and scaling needs
  • API contract governance using OpenAPI, AsyncAPI, protobuf, or equivalent specifications
  • backwards compatibility, versioning, idempotency keys, correlation IDs, and standardized error handling
  • safe data evolution with expand-and-contract migrations, backfills, rollback planning, and reconciliation checks
  • reliability patterns such as timeout budgets, retries with backoff, bulkheads, rate limits, dead-letter queues, and poison message handling
  • observability practices around structured logs, SLOs/SLIs, distributed tracing, dashboards, and user-impacting alerts

Why

A Backend Architect is responsible for more than choosing databases, defining APIs, and scaling services. In production systems, many backend architecture decisions are about operational correctness: whether APIs can evolve without breaking clients, whether data migrations can ship safely, whether retries and queues fail predictably, and whether incidents can be diagnosed from logs, metrics, and traces.

The existing agent already covers backend fundamentals such as databases, APIs, microservices, cloud infrastructure, security, and performance. This change strengthens the role by making contract governance, migration safety, reliability patterns, and observability explicit parts of the Backend Architect's decision-making process.

It also softens microservices-first and horizontal-scaling-first language. A backend architect should choose the simplest architecture that satisfies current and near-term constraints, then document how the system can evolve when scale, ownership, or deployment independence actually require it.

Testing

Not run; documentation-only change.

@bensl84
Copy link
Copy Markdown

bensl84 commented May 20, 2026

Closing — this is my personal fork (bensl84/agency-agents). The canonical project lives at https://github.com/msitarzewski/agency-agents — please re-open your PR there. Thanks!

@youngledo
Copy link
Copy Markdown
Author

Closing — this is my personal fork (bensl84/agency-agents). The canonical project lives at https://github.com/msitarzewski/agency-agents — please re-open your PR there. Thanks!

Did you look at the wrong project?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants