Patterns¶
Implementation patterns for cross-cutting scenarios. Patterns sit between Best Practices (the high-level "what we do and why") and Examples (full working implementations). Use a pattern when you need to solve a specific technical problem and want a vetted approach.
| Pattern | Use when |
|---|---|
| Cosmos DB Patterns | Designing a Cosmos data model or choosing API/consistency |
| AKS & Container Apps for Data | Picking a container platform for Spark, Argo, KEDA-driven stream consumers |
| LLMOps & Evaluation | Building eval harness, content safety, drift detection for AI features |
| Networking & DNS Strategy | Designing private endpoints, Private DNS zones, name resolution |
| Observability with OpenTelemetry | Instrumenting end-to-end tracing across portal → API → AI services |
| Streaming & CDC | Choosing between Event Hubs / ASA / RTI / Debezium for change data |
| Power BI & Fabric Roadmap | Sequencing Power BI workloads onto Fabric Direct Lake |
Microsoft Fabric deep dives
For hands-on Fabric tutorials, feature guides, and production best practices, see the Supercharge Microsoft Fabric companion site.
Why patterns are separate from Best Practices¶
| Document type | Scope | Voice |
|---|---|---|
| ADR | One decision | "We chose X" |
| Best Practice | Operational principle | "When you do Y, do it this way" |
| Pattern | Implementation | "Here's the architecture + code for problem Z" |
| Example | Working code | "Here's a runnable end-to-end implementation" |
If a pattern stabilizes and becomes the platform default, it usually graduates to a Best Practice (the what and why) plus an Example (the runnable how).
How to add a pattern¶
- New file under
docs/patterns/<pattern-name>.md - Use the templated structure: Problem → Pattern → Mermaid diagram → Implementation → Trade-offs → Variants → Related
- Link to relevant ADRs, Best Practices, and Examples
- Open a PR — pattern appears live on next docs deploy