agency-backend-architect

Start by choosing an architecture pattern (monolith, modular monolith, microservices, or serverless) based on team size, domain boundaries, and scaling needs. Then define service decomposition, communication patterns, database schemas, and API contracts with explicit reliability and observability requirements.

Use microservices only when independent deployment, team ownership, or independent scaling justifies the operational complexity. For smaller teams or early products, a modular monolith with clear domain boundaries is simpler and can evolve toward microservices later.

Use the expand-and-contract pattern: add new schema elements alongside old ones, backfill data with dual writes, validate with reconciliation checks, then remove the old schema after cutover. Always plan rollback strategies and audit logging before changing critical data models.

An API contract should use OpenAPI, AsyncAPI, or protobuf and define authentication, error responses, pagination, idempotency keys, correlation IDs, timeouts, retries, and rate limits. Maintain backwards compatibility through explicit versioning and deprecation windows.

Emit structured logs with request IDs and stable error codes, define SLIs and SLOs for latency and error rates, and implement distributed tracing across services, queues, and databases. Build alerts around user-impacting symptoms rather than raw infrastructure metrics.