# Architecture Patterns

> Patterns for system boundaries and change over time: replace without stopping, and give each client a backend shaped for it - decisions measured in routes and releases, not classes.

- kind: category
- category: design-patterns
- canonical: https://aipatterns.dev/design-patterns/architecture
- inspired-by: https://learn.microsoft.com/en-us/azure/architecture/patterns

## What these patterns solve

Class patterns shape objects; these shape systems and the seams between teams. The pressure they answer is longevity: a system must be replaceable piece by piece, and its API surface must serve clients that evolve on different clocks. Both patterns are really ownership decisions - who owns each route, who owns each client's contract - expressed as structure.

**The rule they all enforce: the boundary is the design; everything inside it can change.**

## Members

- [Strangler Fig](https://aipatterns.dev/design-patterns/strangler-fig.md): route all traffic through one interception layer and replace handlers one route at a time, until the legacy system has nothing left to serve.
- [Backends for Frontends](https://aipatterns.dev/design-patterns/backends-for-frontends.md): give each frontend its own aggregation backend, so no client's roadmap waits on a shared API.

## How to choose

- **A legacy system must shrink while it keeps serving:** [Strangler Fig](https://aipatterns.dev/design-patterns/strangler-fig.md). The facade first, then the smallest valuable route, then the trend to zero.
- **Two or more frontends fight over one API's shape or release train:** [Backends for Frontends](https://aipatterns.dev/design-patterns/backends-for-frontends.md). One client with no rival gets no BFF.
- **One cutover is testable and the system is small:** neither. Rewrite it; migration scaffolding for a shed is a shed.

## Prefer no pattern when

- The pain is hypothetical - no team owns the legacy removal, no client actually disputes the shared API.
- The real problem is data entanglement; routing patterns cannot untangle a shared schema.
- The team cannot own one more deployable per boundary.