Across eight modules you have seen the Contoso Airlines platform in pieces. Every lesson introduced one component, justified it and left it running: a network here, a database there, a pipeline, an alert, a budget. It is the only way to learn a platform — nobody takes in fifty services at once — but it is not the way the platform exists. In production everything is connected to everything, and on the day something breaks nobody has time to mentally reassemble eight modules: you need a blueprint.

This lesson draws that whole blueprint and teaches you to read it. It does not explain again what App Service is or how Cosmos DB works: you already know that. What it does is show the whole and the criteria: where a request comes in and where it goes out, what talks to what and through what, why each piece is that one and not another, how much the result costs, which three different versions of this same architecture would make sense in other contexts, and what the team would do differently if it started today with what it knows now.

It is the most important lesson in the module, because reading an architecture as a whole — spotting the single point of failure, the unnecessary coupling, the piece that is surplus to requirements — is exactly what separates somebody who knows services from somebody who designs systems.

Reminder: every euro figure is illustrative and fictitious, and the resource names belong to an invented case study. Real prices vary by region and change frequently.

1. How to read an architecture blueprint
2. The complete Contoso Airlines blueprint
3. Reading it zone by zone
4. A booking end to end
5. The master decision table
6. The platform's numbers
7. Three variants of the same architecture
8. The honest retrospective: what we would do differently today
9. Reference architectures and the Azure Architecture Center
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

A useful architecture diagram is not an inventory of icons: it is a map of flows and boundaries. You always read it in the same order, and it is worth internalizing because it works for any platform, not just this one:

1. Where does traffic come in? Everything arriving from the internet has one single legitimate entry point. If there are two, one of them is a hole.
2. Where are the trust boundaries? The public edge, the private network, the data subnet. Every boundary crossing is a control: WAF, firewall, NSG, private endpoint.
3. What is synchronous and what is asynchronous? A solid arrow means that if the destination goes down, the origin fails. An arrow through a queue or an event means that if the destination goes down, the work waits. It is the distinction that most determines real resilience.
4. Where does state live? Compute can be recreated in minutes; data cannot. Anything that holds state needs a backup, a replica and a recovery plan.
5. Who observes the whole thing? The operations platform takes no part in the flow, but it crosses all of it.
6. What stops anybody creating what should not exist? Governance is not in the flow: it sits above it, in the subscription hierarchy.

The blueprint in the next section is drawn in exactly that order, top to bottom.

Solid arrows are request or data flow; dashed ones are control plane dependencies: identity, secrets, telemetry, backups. The distinction is deliberate: if kv-contoso-pro stops responding, the application does not fall over instantly — the secrets are cached — but if cosmos-contoso-tarifas-pro stops responding, flight search fails on the spot.

And above the whole drawing, without appearing in it, sits the governance hierarchy, which takes no part in any flow but determines what can be created:

A single entry point: fd-contoso-global. Everything else is closed to the internet. Front Door terminates TLS at the point of presence closest to the passenger, applies the wafcontosoglobal WAF before the request reaches any application, caches static content and routes to the healthy region. The applications only accept traffic coming from Front Door, which makes the WAF mandatory rather than optional. Module 2 (global delivery) and module 4 (WAF).

Four compute models coexisting, and that is not inconsistency but fitness for purpose:

This is the zone that stops the platform collapsing entirely when something fails. sb-contoso-pro decouples booking confirmation from everything that happens afterwards: the reservas-confirmadas topic fans out to tarjetas, facturacion and fidelizacion, three consumers that know nothing about each other and that can be down without preventing a sale. evgt-contoso-reservas-pro propagates discrete events, logic-contoso-retrasos-pro orchestrates passenger notifications with connectors instead of code, and evhns-contoso-telemetria-pro absorbs the telemetry firehose heading into analytics. Module 6.

Five engines, one per shape of data: SQL for booking transactions, Cosmos DB for globally distributed, read-heavy fares, MySQL for the legacy content portal, PostgreSQL for crews, and the lake with Synapse for analytics. All of them reachable only through a private endpoint. This is the state, and that is why the backups, the replicas and the recovery plan concentrate here. Module 3 and module 7.

log-contoso-pro is a single workspace where everything converges: applications, platform, security and activity. Alerts, ag-guardia-contoso, the dashboards and the KQL queries all rest on it. And above it, the Base de gobernanza de Contoso initiative prevents anybody creating a resource without tags, outside the allowed regions, with public blobs or without HTTPS. Modules 4 and 7.

This is the flow that justifies the existence of the entire platform: a passenger searches for a Barcelona-Palma flight and ends up with her boarding pass in her inbox.

The important thing about the diagram is where the response to the passenger ends: at step 13. Everything that comes afterwards happens behind the scenes, and that boundary is the most valuable architecture decision in the whole platform. If boarding pass generation fails, the sale is already made and the message is retried.

Every architecture is a list of decisions with their discarded alternative. This is Contoso's, in full:

Contoso's architecture is not the correct architecture: it is the correct one for Contoso. Change the context and the blueprint changes.

What gets removed in the minimal version: firewall, bastion, VMSS, AKS, Synapse, the second region and most of the governance; what stays is MFA, backups, mandatory HTTPS, secrets outside the code and tags, because that is not luxury, it is hygiene. What gets added in the large-enterprise version: a second active region with multi-write Cosmos DB, auto-failover groups, global peering, a permanent on-call team and a bill three or four times bigger; you buy low global latency and an RTO of minutes, and you pay with operational complexity, which is the cost nobody budgets for. What characterizes the regulated version: the architecture barely changes shape, it changes in constraints — where the data may live, who may see it, how long the evidence is kept — and in the fact that every decision needs documentary justification. In all three cases the blueprint is recognizable: it is the same shape with more or fewer pieces.

No real platform comes out right first time. These are the things Marta, Diego and Nuria would do differently:

• Tag from minute one, with a policy. Tags arrived late and dozens of resources had to be retro-tagged by hand before the bill could be allocated. The hereda-centro-coste policy should have existed before the first resource group.
• Start with the landing zone, not with the first machine. The management group hierarchy and the governance initiative were put together when there were already resources inside. It is far cheaper the other way round.
• Do not create vm-motor-disponibilidad-dev. It was born as a quick experiment and survived a year, oversized. Today it would be a container from day one.
• Bicep before the portal. The first resources were created by hand and then had to be written into templates after the fact, with all the subtle differences that drags along.
• A budget and a cost alert on the same day as the first subscription. The doubled bill in the first quarter was spotted late purely because nobody was looking, and the attempt to split Log Analytics by team took two weeks to undo.
• Fewer distinct services. MySQL and PostgreSQL coexist for historical reasons; starting today, there would be a single relational engine alongside SQL.

The conclusion the team wrote into its retrospective is the one worth taking away: almost every mistake was one of ordering, not of choice. The pieces were the right ones; what cost money was assembling them in the wrong sequence.

You do not have to invent every blueprint from scratch. The Azure Architecture Center publishes reviewed reference architectures, with a diagram, components, considerations by Well-Architected Framework pillar and, in many cases, deployable templates:

How to use them well: start from the reference, strip out what you do not need and write down why. The reference is designed for the demanding case; copying it wholesale into a small organization produces an expensive, unworkable platform. The value is not in the drawing, it is in the list of considerations that goes with it.

• Mistaking a diagram for documentation. A blueprint without the decision table explains nothing: a year from now nobody will remember why Cosmos and not SQL.
• Drawing the diagram once. An out-of-date blueprint is worse than none, because it misleads people during an incident. It lives in contoso-infra, next to the templates.
• Drawing everything in one illegible diagram. One overview and several detail views: network, booking flow, governance. Each one answers a question.
• Not distinguishing synchronous from asynchronous arrows. It is the most important information on the blueprint and the most frequently omitted.
• Copying a whole reference architecture. It is designed for the most demanding case; adapt it and document what you remove. And remember that more services is not better architecture: each one adds operational cost, not just billing.
• Tip: keep an architecture decision table with a date, the discarded alternative and the reason. It is the most valuable document a platform has and the one nobody writes.
• Tip: review the blueprint after every incident, and keep it to hand on call. Incidents show you where it was drawn wrong.

Exercise 1. Looking at the overview blueprint and the sequence diagram, identify the three most serious points of failure in Contoso's platform: for each one, exactly what stops working, whether the failure is total or partial, and what it would take to mitigate it with an approximate cost. Rank them by business impact, not by technical severity.

Exercise 2. A hotel chain with 40 employees wants a bookings portal with search, payment and email confirmation, around 8,000 bookings a month and a maximum budget of €1,200/month. Design its architecture starting from Contoso's blueprint: what you keep, what you remove and what you swap for a cheaper alternative. Justify which three things you would never remove even if the budget dropped to €600.

Exercise 3. Contoso wants to sell in Latin America and the team proposes active-active with multi-write Cosmos DB. Analyze the proposal: what problem it really solves, what new problems it creates — especially with db-reservas — what cheaper alternative would cover 80% of the benefit, and what business questions you would ask before deciding.

Solution 1: ranked by business impact. (1) sql-contoso-reservas-pro / db-reservas: it is the only point where the sale is synchronous and irreplaceable; if it goes down, no booking can be confirmed — revenue stops completely — even though search keeps working because the fares are in Cosmos. It is already partially mitigated with zone redundancy and fg-contoso-reservas to North Europe, with a 4 h RTO; getting that down to minutes would require automatic failover and frequent testing, at an additional cost in the region of €1,200-1,500/month. (2) fd-contoso-global: it is the single entry point; if the profile fails or a WAF rule blocks legitimate traffic, the outage is total and instant even though everything else is healthy — the most likely failure is not an Azure one, it is a badly deployed rule, and that is why the real mitigation is cheap: detection mode first, deployment by pipeline and the ability to roll back in minutes. (3) cosmos-contoso-tarifas-pro: if it goes down there is no flight search, which is 90% of the traffic; the failure is partial — somebody who has already picked a flight could still book — but commercially devastating; the mitigation is reads from a second region, relatively cheap, plus an edge cache of fares for the popular route. A note on judgment: a failure of func-contoso-tarjetas-pro does not make the list despite being visible to the customer, because the message waits in Service Bus and the sale has already been charged: exactly what decoupling was meant to achieve.

Solution 2: you keep the shape, not the size. Keep: App Service — a small Standard or Premium v1 plan, not Premium v3 — serverless SQL Database with auto-pause (8,000 bookings a month is a low and very irregular load), Blob Storage for receipts, Application Insights, mandatory MFA, mandatory HTTPS, backups with sensible retention, tags and a budget with alerts. Remove: Front Door and WAF — replaced by your own domain with a managed certificate and, if abuse is a worry, request rate limiting in the application — firewall, bastion, VMSS, AKS, Container Apps, Synapse, the lake, Event Hubs, the second region, PIM and most of the policy initiative, which comes down to three rules — allowed regions, no public blobs, HTTPS only. Swap: Service Bus for a Storage queue, or simply Event Grid with a consumption-plan Function, far cheaper at this volume; Cosmos DB does not apply — the catalog fits in SQL. Plausible total: €700-900/month, within budget. The three things you never remove, not even at €600: secrets outside the code with a managed identity or Key Vault (a leak has nothing to do with company size), tested backups (an accidental deletion closes a small business down, it does not merely inconvenience it), and MFA with no management port open to the internet (an automated attack does not distinguish between an SMB and an airline). They are the three things whose cost of omission is catastrophic and independent of volume.

Solution 3: what it really solves: read latency for distant users — a search from Bogotá against West Europe adds hundreds of milliseconds — and, secondarily, tolerance to a region going down. What problems it creates: multi-write in Cosmos forces you to resolve conflicts, something a fares catalog tolerates but which demands an explicit policy; and above all db-reservas does not come along: SQL Database is not multi-write, so bookings would still be written in West Europe and the user in Bogotá would get fast search and slow confirmation, with the added risk of inconsistency between what they see and what they can buy. On top of that you multiply the RU/s cost, the cross-region data transfer, the deployment complexity — two of everything, in two pipelines — and the incident surface. The alternative that covers 80%: add a read-only region to Cosmos DB with reads from the nearest region and Session consistency, keep writes in Europe and lean on Front Door to bring static content closer and cache the popular routes; you gain almost all the perceived latency for a fraction of the cost and with no conflicts. Business questions to ask first: what real volume is expected in Latin America, and over what timeframe? Is there a legal data residency requirement in any destination country? How much lost conversion do we attribute to latency today, measured rather than assumed? Do we have a team to run two active regions 24x7? The answer to the last one usually settles the discussion.

You now have the complete blueprint of Contoso Airlines and, more importantly, the method for reading any other: where traffic comes in, where the trust boundaries are, what is synchronous and what is asynchronous, where state lives, who observes it and what prevents anybody creating what should not exist. You have seen the six zones — edge and global delivery, application, integration, data, operations and governance — with their real connections, and the distinction between request flow and control plane dependency, which is what explains why some outages are noticed instantly and others are not noticed at all.

You have followed a booking end to end, from search to boarding pass, through Front Door, the WAF, App Service, the API, Cosmos DB, SQL Database, Service Bus, the function and storage, with the key boundary clearly marked: the response to the passenger ends before the asynchronous work begins. And you know which module built each piece, which is how you turn eight separate modules into a system.

You have the master decision table — every choice with its discarded alternative and its reason — the numbers for the platform — €12,550/month, €0.136 per booking, 99.9%, RPO 15 min and RTO 4 h — three variants of the same architecture for different contexts with what is removed and what is added in each, the honest retrospective with its central lesson — almost every mistake was one of ordering, not of choice — and the Azure Architecture Center as a starting point so you never have to draw from scratch.

With the blueprint in front of you, the natural question is whether it is drawn well. The next lesson answers that with the framework Microsoft uses for exactly this purpose: the Azure Well-Architected Framework, its five pillars — Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency — its trade-offs between pillars, and a pillar-by-pillar audit of this very platform that will say what it meets, what it does not meet and what was consciously decided against.