# Worked Architecture Examples

> Three designs worked through from requirements to an injected failure: an enterprise AI assistant, an order API that survives a region, a paying agent.

- Web page: https://www.alesanalytics.com/architecture/worked-examples
- Markdown: https://www.alesanalytics.com/architecture/worked-examples.md
- Part of: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md), section "Failure and design"
- Last verified: 13 October 2026
- Publisher: Ales Analytics

## 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

**Figure: Reference architecture: an internal AI assistant over SharePoint, Confluence and a ticketing system, on Azure.** Five thousand employees on compliant devices sign in through Microsoft Entra ID (Tier-0) with Conditional Access. Inside a virtual network in an EU region, reached only through private endpoints: the assistant app, which holds the user's token issued to the app; an AI gateway for authorization, quota, redaction, routing and metering; Azure AI Search with a hybrid keyword and vector index and a reranker; Microsoft Foundry Models in an EU deployment with no training on prompts; and a ticket tool that exchanges the user's token on-behalf-of for one issued to the ticket API, sending an idempotency key with every ticket. Sources: SharePoint Online through delegated Graph access or Sites.Selected, and Confluence through a connector identity with ACLs synchronised. Azure Monitor records latency per stage, citations, denials and cost. Authorization is enforced at four points: 1, the ACL filter in the index; 2, a re-check of the top results at the source; 3, Purview's processing decision for Microsoft 365 content; 4, the ticket API's own authorization. The user's token is never forwarded.

**Azure**

Foundry Models in an EU deployment, reached over private endpoints, with Entra ID for identity. The index sits in the same region under a customer-managed key. SharePoint is read through delegated Graph access or `Sites.Selected`.
**AWS**

Amazon Bedrock in an EU Region, reached over PrivateLink. The index stays in-region with a customer-managed KMS key. Entra ID can remain the workforce identity provider, federated into AWS.
**Google Cloud**

Gemini Enterprise Agent Platform in an EU region, reached through Private Service Connect, with the index in-region under a customer-managed key.

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](https://www.alesanalytics.com/architecture/numbers.md)).
- 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.

Should you have any questions regarding this page, please contact us at solutions@alesanalytics.com.

## Sources

1. [Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region](https://aws.amazon.com/message/101925/). Amazon Web Services, 2025. AWS's post-event summary for 19 and 20 October 2025: a race in DynamoDB's DNS automation left an empty record, with impact in three phases ending at 2:20 PM PDT on 20 October.

## Where to go next

- Previous: [28 Reference Architecture Scenarios](https://www.alesanalytics.com/architecture/scenarios.md)
- Next: [Architecture Misconceptions and False Abstractions](https://www.alesanalytics.com/architecture/misconceptions.md)
- Overview and every page: [Enterprise Architecture Atlas](https://www.alesanalytics.com/architecture.md)
- The whole site in one file: https://www.alesanalytics.com/llms-full.txt