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: 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: 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. 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. 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.