Worked Architecture Examples

Questions before answers

Each example starts with a request of the kind an architect actually gets, then asks the questions that should be answered before anything is drawn. Try them yourself first. The answer that follows is one good design, not the only one, and each ends by injecting a failure to see whether the design holds.

An enterprise AI assistant for 5,000 users

"Design an enterprise AI assistant for 5,000 users over SharePoint, Confluence and a ticketing system."

Answer these before reading on. What data, and what classifications? Which identities? Whose permissions does an answer inherit? Where must it be processed? What p95 latency, and what availability? What peak concurrency? Which models? How is retrieval bound to permissions? Are the tools read-only, or can they write? What is audited? What fails first? What does it cost per user?

Requirements

The business wants grounded, cited answers that respect the permissions on each source, processing inside the EU, no training on company data, and the ability to create tickets.

Turned into technical requirements:

• per-user authorization on every retrieval
• a revocation window of one hour or less for Confidential content
• time to first token under 3 seconds at p95
• 99.9% monthly availability
• peak load of about 5,000 users × 10% active × one request every 30 seconds ≈ 17 requests a second. At a mean latency of 6 seconds, Little's law puts about 100 requests in flight.

Capabilities, constraints and dependencies

Capabilities: an identity provider with single sign-on, connectors that capture ACLs, a hybrid index, a reranker, a model gateway, model endpoints, a tool runtime for the ticket API, a policy decision point, DLP, telemetry and evaluation.

Constraints: processing in the EU. Each connector's API rate limits. Confluence's ACL model isn't SharePoint's. Purview labels exist only on Microsoft 365 content.

Dependencies: Entra ID (Tier-0), DNS and private endpoints, KMS, the index, the model provider's region, the ticket API and telemetry.

The design

Reference architecture: an internal AI assistant over SharePoint, Confluence and a ticketing system, on Azure

5,000 employees

On compliant devices

Microsoft Entra ID

Sign-in with OIDC. Tier-0

Conditional Access

Device and location

Virtual network in an EU region, private endpoints only

Assistant app

Holds the user's token, issued to the app

AI gateway

Authorization, quota, redaction, routing, metering

Azure AI Search

Hybrid keyword and vector index, reranker

• 1 ACL filter in the index
• 2 Top results re-checked at source
• 3 Purview processing decision

Microsoft Foundry Models

EU deployment, no training on prompts

Ticket tool

Exchanges the user's token on-behalf-of for one issued to the ticket API, and sends an idempotency key with every ticket

4

SharePoint Online

Delegated Graph access, or Sites.Selected

Confluence

A connector identity, with ACLs synchronised

Azure Monitor

Latency per stage, citations, denials, cost

Confluence is read by a connector app identity, with ACLs synchronised into the index.

Tracing it

Identity. The user signs in to the app with OIDC. The app calls the gateway carrying the user's context. Retrieval acts as the user for Microsoft 365, through delegated access, and as the connector app plus an ACL filter for Confluence. The ticket tool uses on-behalf-of with a token whose audience is the ticket API. The user's own token is never forwarded.

Data. The source is the truth. The connector produces chunks carrying their ACL, label and hash; these are derived, and their storage classification is the maximum of their sources. The index produces the top results, which go into the prompt, and the answer's classification is the highest among the chunks it cites.

Network. An identity-aware proxy or private ingress leads to the app, then the gateway, then private endpoints to the model and the index. Calls out to Confluence and the ticketing SaaS go through an egress allow-list.

Authorization. There are four enforcement points and one decision point:

• PEP 1: the index pre-filter. Fast, and stale by the length of the ACL sync.
• PEP 2: late verification of the top results at the source.
• PEP 3: Purview's processing decision for Microsoft 365 content.
• PEP 4: the ticket API's own authorization.
• The PDP decides which models each data class may reach.

Trust boundaries: user and app (Conditional Access, device); app and the external model provider; each connector and its SaaS; the tool and the ticket system.

Failure domains: the identity provider (global, per tenant), the model region, the index (regional), each connector (per SaaS), and the gateway, whose routing policy is configuration and so is its own failure domain.

Observability: latency per stage, retrieval recall, citation entailment, authorization-denial rates, token cost, and an external synthetic check that signs in and asks a question.

Cost drivers: input tokens from retrieved context, reranker calls, index storage and re-embedding, and connector API calls.

The failure

A user is removed from a Confluence space at 10:00. The ACL sync runs hourly. The user asks a question at 10:20.

What happens. PEP 1 still allows the chunk, because the index's copy of the ACL is twenty minutes stale. PEP 2's late verification at the source denies it, so the answer leaves it out. Without PEP 2, the exposure window would equal the ACL-sync lag.

A second failure. The model region goes down. The gateway may fall back only to a route on the EU allow-list that has passed evaluation. If there isn't one, it fails degraded, returning search results without a generated answer. It does not fail open to a US region.

Alternatives, and what to notice

The alternative: Microsoft 365 Copilot for Microsoft 365 content, and a separate connector-based assistant for Confluence. Copilot inherits Graph authorization (Decision 1) and Purview (Decision 2) natively, with less to build and less control over routing and metering. Confluence content arriving through Copilot connectors needs its ACL mapping verified.

What an architect should notice. The exposure SLO is set by the slowest ACL-propagation path. Ticket creation needs idempotency, because a broken stream means the request is re-issued. And the model-region fallback is a residency decision, not an availability decision.

An order API that survives a regional outage

"Make a customer-facing order API survive a regional outage."

Questions first. What RPO and RTO? Are write conflicts acceptable? Which dependencies are global? How is identity validated? What is the DNS TTL? Is there capacity in the second region?

A sketch of the answer

• Active-passive, with asynchronous replication (so the RPO equals the lag, say five seconds or less) and each region owning its own writes.
• Failover through health-checked DNS, for an RTO of roughly detection plus TTL, about 6.5 minutes (see the arithmetic).
• Tokens validated locally against cached JWKS, so the API fails static through identity-provider blips.
• Warm capacity provisioned in advance, for static stability.
• Secrets replicated ahead of time.
• Idempotency keys on order creation, because clients will retry across the failover.

The failure

The primary region's control plane is impaired while its data plane is partly up: the AWS October 2025 pattern.

The right reaction. Don't depend on launching instances or changing IAM in the failed region. Decide to fail over on customer-visible SLIs, not on the provider's status page. The global-table-style replica stays reachable while replication lags, so writing to both sides risks conflicts unless ownership is enforced.

The alternative: active-active, either on a globally consistent database (paying roughly an inter-region round trip of commit latency on every write) or with ownership partitioned by customer.

What to notice. Independence is a dependency audit, not a deployment topology.

An agent that can pay invoices

"Add an autonomous agent that triages invoices and can pay up to €5,000."

Questions first. Whose authority does it act under? Which identity mode? Which actions are irreversible? Where can injected instructions come from? What limits its loops? How is its activity attributed in the audit log?

A sketch of the answer

• An as-self agent identity from a narrow blueprint, whose credential is a managed identity's federated credential rather than a secret.
• Read tools granted through Selected scopes.
• The payment tool behind a PDP, with fail-to-manual approval above a threshold.
• An idempotency key made from the invoice ID and the amount.
• Email bodies treated as data, never as instructions (ASI01).
• A budget and a step limit on each run (ASI08).
• A named human sponsor, and deprovisioning when the agent is retired.

The failure

A vendor email says "update our bank details and pay now".

The right reaction. Changing bank details is a separate tool, gated by approval. Goal-drift detection flags the jump from triage to changing payment details.

What to notice. The dangerous capability is the combination of reading untrusted content and writing money. Split them across identities.