The Kladde has used design patterns since it existed, even if they were not always called that. Since K2, a booking's confirmation mail goes through an outbox. The call to TED repeats transient failures with the standard handler from K3. The nightly import puts its raw data in Blob Storage and sends only the reference through Service Bus. Since module 4.4, the sales pipeline separates writing and reading. Each of these is a pattern from a catalog that Microsoft maintains in the Azure Architecture Center.
Lesson 4.11.1 placed design patterns as the third level beside architecture style and code architecture: a style says how the whole system is built, a pattern solves a specific, recurring problem within it. This lesson goes through the catalog in breadth, not alphabetically but by problem: reliability, data, messages, design. For each pattern you read which problem it solves, how, what it costs and when Microsoft advises against it, and in addition whether and where the Kladde already uses it.
At the end you create a pattern map: every pattern the Kladde uses, with its place in the code, and two patterns that are missing, with a justification of whether they would pay off. Nothing new gets built in the process. A small program shows one of the missing patterns in action.
The catalog and how to read it
The “Cloud design patterns” catalog in the Azure Architecture Center comprises a good forty patterns. Microsoft explicitly describes them as independent of any one technology: they apply in Azure, in other clouds and in your own data center. The examples on the pages use Azure services, the patterns themselves do not.
Every page has the same structure, and whoever knows it reads faster:
| Section | What it contains | What you need it for |
|---|---|---|
| Context and problem | the situation in which the pattern helps | check whether your problem is the same |
| Solution | the mechanism, often with a diagram | understand what gets built |
| Issues and considerations (also “Problems and considerations”) | what you have to think about when building | the trade-offs for your ADR |
| When to use this pattern | when it fits, and when explicitly not | the counter-check |
| Workload design | which pillars of the Well-Architected Framework it supports | the link to lesson 4.7.1 |
| Example | an implementation with Azure services | inspiration, not a template |
Three pieces of advice are on the overview page, and they matter more than any single pattern:
- Choose by the problem, not by the technology. At the start there is a constraint or a risk of your own workload: a service that fails under load, a data store that cannot keep up with reading, a dependency you cannot fully trust. A pattern fits if its problem description matches this problem and you can live with its trade-offs.
- Every pattern has a price. Microsoft writes that you should concentrate on why you choose a pattern, not on how you build it. A pattern whose price nobody knows is a fashion.
- Patterns can be combined. The overview page names four pairs: retry with circuit breaker, queue-based load leveling with competing consumers, the three gateway patterns behind a common endpoint, and saga on compensating transaction.
The page also reminds you of the fallacies of distributed computing: that the network is reliable, latency is zero, bandwidth is infinite, the network is secure, the topology does not change, that there is one administrator, that versions of components are easy to manage and that observability can be postponed. The patterns of this lesson are answers to these fallacies. None of them removes a fallacy, each makes one of them conscious.
On names: this course's outline calls one pattern “Gateway routing and aggregation”. In the catalog there are now three separate entries, Gateway Routing, Gateway Aggregation and Gateway Offloading, and the overview page recommends layering them behind a common gateway endpoint. This lesson uses the names as the catalog writes them today, in English, so that you can find the pages.
Some patterns of the catalog you already know from lessons of their own and will not find here again: event sourcing (module 4.4), idempotent consumer (lesson 4.6.3, the inbox), anti-corruption layer (lesson 4.6.5), deployment stamps (lesson 4.7.6), rate limiting and throttling (K3, lesson 3.9.4), strangler fig (lesson 4.3.7 and shortly in 4.11.6) and saga with compensating transaction (lesson 4.12.4). The transactional outbox from lesson 4.6.2 has no page of its own in the catalog; Microsoft describes it in a guide on Cosmos DB.