19 — Design and Cloud Patterns: Strangler, Gateway, BFF, and Friends

"Just architecture buzzwords" was how I dismissed cloud design patterns, until the names started compressing real experience. Writing them down turned the jargon into a toolbox: cloud design patterns are named, reusable solutions to common structural problems — migrating a legacy incrementally, routing to many services through one endpoint, giving each frontend its own backend — and the names compress a lot of hard-won experience into a single phrase. [1][2] Knowing the names lets me reach for a known solution instead of reinventing one.

The framing that landed is that patterns are not prescriptive; they are _vocabulary_. When someone says "let's use a strangler fig for the migration," everyone in the room who knows the pattern shares the same mental picture — replace the legacy piece by piece until the new system has strangled the old one — without a whiteboard. The patterns below are the ones I actually reach for.

Patterns for evolving the system

These patterns are about how a system changes over time — migrating off a legacy, splitting things apart, consolidating things together.

• Strangler fig incrementally migrates a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features are replaced, the new system eventually replaces all of the old one, strangling it until it can be decommissioned [3]. The alternative — a risky big-bang rewrite — is what this pattern exists to avoid.
• Anti-corruption layer implements a facade or adapter between subsystems that don't share the same semantics, translating requests from one to the other. It ensures an application's design is not limited by dependencies on outside subsystems. First described by Eric Evans in Domain-Driven Design [4]. Essential when integrating with a legacy or third-party system whose model would otherwise pollute your clean domain.
• Backends for Frontend (BFF) creates separate backend services for specific frontend applications or interfaces, avoiding the customization of a single backend for multiple interfaces. First described by Sam Newman [5]. A web client and a mobile client get their own tailored backends, each returning exactly the shape that client needs.

Patterns for routing and consolidation

The gateway family is about putting a single point in front of many services and giving it a specific job.

• Gateway routing routes requests to multiple services or instances using a single endpoint. Useful to expose many services on one endpoint, to load-balance across instances, or to expose multiple versions of the same service on one endpoint [6].
• Gateway aggregation uses a gateway to combine multiple individual requests into one, when a client would otherwise make many calls to different backends to perform a single operation [7].
• Gateway offloading moves shared or specialized functionality (SSL certificates, auth, logging) into the gateway proxy, simplifying application development [8].

These three compose — a single gateway can route, aggregate, and offload simultaneously. That is exactly what products like NGINX, Kong, and AWS API Gateway do.

Patterns for coordination and structure

• Leader election coordinates collaborating instances by electing one as the leader that manages the others, preventing conflicts and contention for shared resources [9]. Essential when exactly one instance must run a job (a scheduled task, a stream processor) even though many are deployed for redundancy.
• Pipes and filters decomposes a task that performs complex processing into a series of separate, reusable elements that can be deployed and scaled independently [10]. Classic for stream-processing pipelines.
• Static content hosting deploys static content to a cloud storage service that delivers it directly to the client, reducing the need for expensive compute instances [11].
• External configuration store moves configuration out of the deployment package into a centralized location, for easier management and sharing across instances [12].
• Compute resource consolidation consolidates multiple tasks into a single computational unit to increase utilization and reduce cost and management overhead [13] — the counterpoint to over-zealous microservices, where too many tiny services each idle-waste resources.

How I use this

The patterns are a vocabulary I use during design conversations to converge quickly. When migrating a legacy, I reach for strangler fig plus an anti-corruption layer — never a big-bang rewrite. When serving multiple frontends with different needs, I consider a BFF per frontend instead of overloading one. When I have many services behind one public face, I put a gateway in front and decide whether it should also aggregate and offload. And the discipline I keep is to treat each pattern as a trade-off with a cost (more moving parts, more latency, more operational surface) — not a default. Reaching for a pattern because I can name it, without weighing its cost, is how systems accrete complexity they do not need.

References

[1] Microsoft, "Cloud design patterns," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/

[2] Microsoft, "Design and implementation patterns," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/category/design-implementation

[3] Microsoft, "Strangler fig pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig

[4] Microsoft, "Anti-corruption layer pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

[5] Microsoft, "Backends for Frontends pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/backends-for-frontends

[6] Microsoft, "Gateway Routing pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-routing

[7] Microsoft, "Gateway Aggregation pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation

[8] Microsoft, "Gateway Offloading pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-offloading

[9] Microsoft, "Leader Election pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/leader-election

[10] Microsoft, "Pipes and Filters pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters

[11] Microsoft, "Static Content Hosting pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/static-content-hosting

[12] Microsoft, "External Configuration Store pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store

[13] Microsoft, "Compute Resource Consolidation pattern," Azure Architecture Center. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/compute-resource-consolidation