Architecture Pattern

An architecture pattern is a general, reusable arrangement of software components that answers a recurring structural question — how work is divided, how the pieces communicate, and what you gain and give up by choosing that shape. Layered systems, client-server, event-driven, microservices, and pipe-and-filter are all architecture patterns. They sit a level above design patterns: where a design pattern shapes a class or a function, an architecture pattern shapes the whole system.

• System-scale decisions - A pattern settles the big questions about boundaries and communication before a single endpoint is designed.
• Named trade-offs - Picking a pattern is picking which failure modes and costs you accept in exchange for its strengths.
• Portable across stacks - The same patterns reappear across languages, clouds, and API styles, which is what makes them worth naming.

For APIs, the architecture pattern a team commits to determines the API style that follows and the artifacts it can produce — a request-response pattern points toward OpenAPI, an event-driven one toward AsyncAPI. When I review a provider, the clarity of its underlying architecture pattern shows up directly in how consistent, governable, and agent-ready its API surface ends up being.