Architectural Design Patterns

Architectural design patterns are the named, reusable solutions that engineers reach for when they organize a system — layering, client-server, event-driven, microservices, publish-subscribe, and the rest. They are not code you copy; they are templates for how components are arranged and how they talk to each other, distilled from decades of teams solving the same structural problems over and over. In the API world they are the shapes underneath the styles: REST, event streaming, and message-driven designs each lean on a small set of these patterns.

• Vocabulary, not implementation - A pattern gives a team a shared name for a structure so architecture conversations move faster and stay honest.
• Trade-off encoded - Each pattern carries known strengths and costs, so choosing one is really choosing which problems you are willing to live with.
• Cross-cutting - The same handful of patterns show up whether you are designing a monolith, a mesh of microservices, or an event-driven backbone.

In practice these patterns are where API design starts long before an OpenAPI or AsyncAPI document exists. Whether a provider ships a request-response REST surface or an event-driven stream shapes everything downstream — the artifacts, the governance rules, and how agent-ready the API turns out to be. When I score providers, I am often really scoring how deliberately they applied an architectural pattern, because a clear pattern is what makes an API legible to both humans and the machines now consuming it.